Drag and Drop files no longer works across monitors

[borring]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Open up two file managers
2. Move one window to a different monitor
3. Drag a file from one window to the other

Expected behavior
File is moved from one folder to the other.

System information:

Distribution: Fedora Linux
GNOME Shell 44.2
Display server: Wayland
PaperWM branch/tag: develop-redux
PaperWM commit: fdb072618e0242cacc0e62d44a43b44c3a632f31
Enabled extensions:
- freon@UshakovVasilii_Github.yahoo.com
- gsconnect@andyholmes.github.io
- blur-my-shell@aunetx
- appindicatorsupport@rgcjonas.gmail.com
- just-perfection-desktop@just-perfection
- paperwm@paperwm-redux.github.com
- user-theme@gnome-shell-extensions.gcampax.github.com

Additional context
This used to work, but I think it might've been back in the Gnome 43 days.

[jtaala]

Hmm - I don't think I've even done a drag/drop files across monitors...

In any case, it may have been caused by ad1fc14. This fixes drag/drop windows between monitors but it's feasible that it interferes will drag/drop of non-window items?

I don't have a monitor I can plug into and test, but if you're able to test on develop branch something (that doesn't have that commit) and see if it drag/drop files there.

Once I can get to a monitor I ca also test.

[borring]

I will try on the develop branch. For sake of testing, does it usually require a full logout of GNOME or just disable+re-enable?

[Lythenas]

Yes, on Wayland you need to completely log out and back in. On X11 you could do Alt+F2 and type in r. To just restart Gnome.

[Lythenas]

Btw I can confirm this issue on the submission-to-extensions.gnome.org branch on gnome 44 (opened "Files" two times and tried to drag files between them).

@jtaala I'm not sure if that is really related to ad1fc14. It could be. But since we are often displaying clones instead of the actual actors, it could be that the drag-and-drop simply does not work when you try to drop on a clone. I'm assuming here that all windows on the non-active monitor are only clones.

If you move to another monitor while dragging a file it won't activate the other monitor. Fixing this might already fix the issue completely.

I will also test this on gnome 42 next week, in case that makes any difference.

[jtaala]

Hey all, so I can confirm that it's not caused by https://github.com/paperwm/PaperWM/commit/ad1fc14.

Reason being is the added grab-op-end is only relevant for a window grab/drag (not other items dragging) - so the code added doesn't even get used/triggered.

However, what I believe is causing this is simple the enterMonitor doing it's thing. So, how it works is that when another monitor is not selected, it's "ClickOverlay" is activated (basically an actor sits over top of the window (which are actual metawindows, not clones) and is ready to detect the move entering that space (or clicks), which point the ClickOverlay gets deactivated (bascially disables it).

So, essentially, the file drag isn't actually getting to the actual target window (since the ClickOverlay is active and sitting in between them).

We haven't changed that code for a while though - so I'm not sure if/when that drag was working.

[jtaala]

It's very related to #389 though.

[jtaala]

The ClickOverlay approach makes it so that when your mouse moves to another monitor, that monitor is activated and the most-recent-used window is selected (unless of course you're dragging/dropping a window there, then that window gets selected... which is what ad1fc14 fixed).

I'm not entirely sold on that behaviour, as #389 points out some issues there (including the issue we're seeing re the file drag/drop issue). It's also quite different from default gnome behaviour - but then again I don't use multiple monitors that much so not sure what the best approach here is.

We could remove the ClickOverlay approach - would simplify the code quite a bit, but we'd lose the "activate monitor window when move enters it's space" behaviour.

[jtaala]

In any case, before working on fixing this, we need to get #556 merged, which I'm planning on doing as soon as can.

If ad1fc14 caused a regression I was going to hold off but that doesn't seem to be the case here.

[borring]

I booted into Fedora 37 just to run paperwm on 43 to check. It looks like the drag and drop functionality works across monitors there.

So the regression was introduced when upgrading from Gnome 43 -> Gnome 44. It was not caused by any change on PaperWM's side.

[Lythenas]

After disabling PaperWM on Gnome 44 the file drag and drop between monitors works. So I think this is a PaperWM problem and not a Gnome problem.

@jtaala just to reiterate: The second monitor is not being focused when dragging a file there. And I think that is the problem. So maybe the ClickOverlay needs an additional "file drag event" listener in addition to the simple "on mouse enter". It that is possible, I think that would be the easier fix (instead of removing the ClickOverlay).

[borring]

I'm not saying that it's not a PaperWM problem. It definitely is. I'm just saying that it was not caused by any particular change in PaperWM. So it's not really a bug that can be bisected, since that's what I intended to do.

[jtaala]

I'm not saying that it's not a PaperWM problem. It definitely is. I'm just saying that it was not caused by any particular change in PaperWM. So it's not really a bug that can be bisected, since that's what I intended to do.

All good @borring - 100% knew what you meant.