ba9fa54b92
source_to_proxy (called by mapFromSource) was unconditionally creating a mapping for the parent of the given source index, even if that parent is in fact filtered out in the proxy. That mapping would then just say "-1" for the (also filtered out) child row. Afterwards, inserting a visible child (which makes the parent visible, in a recursive QSFPM) would see that the mapping for the parent already exists and fail to update it properly. Various symptoms could ensue, such as an out-of-bounds access in gm->proxy_rows.at(source_parent.row()) in a subsequent call to can_create_mapping (as I had on KMail startup for years, randomly) or a visible child that fails to appear (as in the unittest). Fixed by using create_mapping_recursive() which returns 'end' if the row is filtered out, going up the tree if necessary to create mapping for parents on demand (so that the call to filterAcceptsRow is cached). Fixes: QTBUG-76976 Pick-to: 6.8 Change-Id: I25a3bf6b147092c1231ab6441e636264fd0c4222 Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io> (cherry picked from commit 90a82ad8e59792fb430a1a11c9a0c2f94878303e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>