Nesting adjacent nodes fails if any node after them has a child

[ValShaped]

Steps to reproduce:

1. Create three nodes (A, B, and C in improper-nesting.charm)
2. Create a node D under C
3. Select nodes A and B
4. Nest nodes A and B

improper-nesting.charm.zip

The panic handler segfaults if C and D have the same offset(?) (still trying to figure this one out)

Backtrace:
backtrace.txt

Video:

2024-08-04.03-10-08.mp4

[misson20000]

I am able to reproduce the panic, but it's recoverable for me; I'm not getting the segfault when the crash dialog opens. Can you get a GDB backtrace for the segfault?

[misson20000]

This is a tricky issue. While we're updating the panel on the left, we emit the items-changed signal, which causes GTK to observe an intermediate state and start querying whether items are selected or not. The selection model has already updated to the new version of the selection, which references the new version of the document where the paths have changed, but the list model underlying the selection model is still in the middle of updating and is still referencing paths that existed in the old document.

This means that when we update the list to remove "root.A" and "root.B" and add "root.", "root..A", and "root..B", GTK tries to query whether "D" is selected before "root.C" and "root.C.D" have had a chance to change their paths to reference the new version of the document. It then winds up querying the selection model for the new version of the document using list items that are still referencing the old version of the document with paths that are no longer valid.

This invalid state only exists temporarily while the underlying list model is updating, so even though are cases where this could produce incorrect behavior that doesn't crash (because the invalid paths still resolve to actual nodes), you would never see it because the list model would finish updating and prompt GTK to re-query the selection.

I've kicked the can down the road here by deferring the items-changed signal emission until later in the updating process, but it's technically still wrong because it's still exposing invalid intermediate state to GTK, GTK just isn't querying it in ways that observe the invalid parts of the state now. I think the correct fix would be to have each list item keep track of the version of the selection model that it is up-to-date for, instead of having a single selection model for the entire list. That way the intermediate states, while not entirely consistent, are at least somewhat valid. I don't think we can hide the intermediate states from GTK, unfortunately.