g-s/master doesn't always allow moving windows to other workspaces or crashes while moving windows to workspaces [regression compared to 3.32]
Since some weeks I observed an abnormal behaviour regarding the workspaces. This includes:
- Moving windows to a new workspace before the the first workspace (creating a new "first" workspace and moving the dragged window to it)
- Multiple empty workspaces at the end of the workspace list that do not disappear
- g-s crashing when moving windows to new workspaces. With new workspaces I mean in this context that If you have the workspaces A-B-C, the workspaces B and C are empty due to the Bug 2, and you move a window between workspace A and B, it will create a new workspace. If you try Case 3 2-3 times, g-s will crash without leaving any coredump in either coredumpctl or leaving some note in journalctl.
Here is screencast where you can see case 1 and 2:
In this screencast, you can first see how two windows are opened (Visual Studio Code (XWayland Application (I don't know whether this matters) via the overview) and g-t (via a keyboard shortcut))
Then, you can see how I move the g-t window above the VS Code window which should normally create a new workspace where this window will also be moved to (but doesn't happen here). Sometimes this step might also lead to a crash, but not always. This works completely fine with the 3-32 branch.
Another thing you might notice in this cast is: There are 3 workspaces (let us name them A, B and C), but the workspaces B and C are empty. Usually, only 1 workspace at the end is empty, not more than 1. I don't know a specific reproducer for this. It just happens after some time using g-s. For this screencast, I restarted g-s via login + logout and basically did the same thing in the screencast before using the screencast to record this issue. No extensions are used here. This also works correctly in the 3-32 branch, but not in current master.
With this scenario in this screencast with the workspaces A, B and C, we can now start a new window (e.g. g-t) and move this window between workspace A and B. This should technically create a new workspace between these two workspaces and move this window to it. Usually this works on the first try. If I do this a second time, g-s will crash (third case from the aforementioned cases above). g-s won't leave some trail in journalctl or coredumpctl unfortunately. This case depends on case 2 and therefore also doesn't happen in the 3-32 branch.
Regarding the workspace setting: I use the dynamic workspace setting (and obviously the vertical workspace setting). I suspect that the issue started with !575 (merged), but can't be 100% sure, since I cannot build g-s with reverting these commits due to a merge conflict when reverting these commits, but I am very sure that it started with these commits from that MR.