Fix tiling break on chromium tab move

[javs]

When a chromium tab is moved, the code is grabbing a window (inGrab is true), but the window is new (selectedInColumn is null). Use the code path for new windows instead.

This prevents the following backtrace:

JS ERROR: TypeError: grabWindow is null
layoutGrabColumn@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:544:63
layout@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:746:26
insertWindow@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:4147:11
window_created/<@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:3340:25
connectOneShot/id<@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/utils.js:522:20
@resource:///org/gnome/shell/ui/init.js:21:20

Closes #1016

[javs]

I think I got this right, but let me know if I missed anything.

I tested it a bit and the behavior now doesn't horribly break the extension any more, you can pull out a tab and it adds as a new column.

For reference, here's the full log before the changes. I think the errors after are just a side effect of the exception, but I wasn't sure about the "Invalid window geometry" one being involved or not.

Apr 17 17:59:37 host gnome-shell[1846]: Invalid window geometry for xdg_surface@83. Ignoring for now, but this will result in client termination in the future.
Apr 17 17:59:37 host gnome-shell[1846]: JS ERROR: TypeError: grabWindow is null
                                          layoutGrabColumn@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:544:63
                                          layout@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:746:26
                                          insertWindow@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:4147:11
                                          window_created/<@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/tiling.js:3340:25
                                          connectOneShot/id<@file:///home/user/.local/share/gnome-shell/extensions/paperwm@paperwm.github.com/utils.js:522:20
                                          @resource:///org/gnome/shell/ui/init.js:21:20
Apr 17 17:59:37 host gnome-shell[1846]: meta_dnd_actor_drag_finish: assertion 'META_IS_DND_ACTOR (self)' failed
Apr 17 17:59:39 host gnome-shell[1846]: No rect to shove into found!
Apr 17 17:59:39 host gnome-shell[1846]: No rect to shove into found!
Apr 17 17:59:39 host gnome-shell[1846]: No rect to shove into found!
Apr 17 17:59:39 host gnome-shell[1846]: No rect to shove into found!
[more ...]

Thanks!

[jtaala]

Thanks @javs!

Note though, I haven't been able to reproduce this issue with chromium or chrome yet (installed flatpak versions of these and don't see the reference issue happening).

[javs]

Regardless of reproducibility (although I added more notes on the ticket about that), I think it's clear something is definitely wrong with layoutGrabColumn before the patch:

1. It can't be called with a null window, yet it is (grabWindow is null).
2. The call site in the layout function can deal with the two situations: grabbing an existing window (window is not null) or laying out a newly created window (window is null).
3. Peeling a tab is creating a new window, so it doesn't seem incorrect to test for the window being null and choose the other path.
4. Currently it only checks for inGrab, which wouldn't be wrong wither. I suppose there may be a race somewhere in addWindow that only happens when chrome is in native wayland mode, but I've not found it.