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 https://github.com/paperwm/PaperWM/issues/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 https://github.com/paperwm/PaperWM/commit/ad1fc1420beabcb4c7498d9c18a9d3b7937623ae 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.

[jtaala]

Struggling with this one - bascially, no events at all are passed to the ClickOverlay when dragging a file over it. Tested with captured-event signal. Basically means, that the ClickOverlay has no idea that a dragging action is over it... we need some way of detecting something to we can deactiviate the clickoverlay.

There must be some signal or property we can monitor to detect file/object drags. Just haven't found it.

On a sidenote, if you grab->drag and (while still keep click-down on drag) alt-tab to the window on the other monitor (which deactivates the ClickOverlay) then drag file over nautilus works.

[jtaala]

Hey @borring @Lythenas.

Just created a PR fix fixes this issue. Could you please test out this?

git fetch --all
git checkout fix-559-drag-n-drop-across-monitors
./install.sh

and then logout/login.

Let me know how it goes.

[borring]

@jtaala fixed! Although I didn't rerun ./install.sh

[Lythenas]

@jtaala this does not seem to do anything for me :( I also can't find the console.debug line in the logs (but I'm not sure if I'm looking in the correct place.

Just to confirm what I tried:

1. Open "Files" on monitor 1
2. Open "Files" on monitor 2
3. Try to drag a file from monitor 1 to monitor 2 (and vice versa)
4. Monitor and "Files" window where I drag to is not focused and I can't drop the file there

I also noticed that if I move the mouse very slowly to the other monitor it also does not get focused. But I'm not sure if that is new behavior or old. I can even continue to move the mouse on that monitor. It only gets focused when I move the mouse faster or when I click.

[jtaala]

hmm - def double check your .local/share/gnome-shell/extensions/ folder - just in case you installed the extensions.gnome.org version or there's something up there.

I also noticed that if I move the mouse very slowly to the other monitor it also does not get focused. But I'm not sure if that is new behavior or old

That sounds like the older behaviour.

[jtaala]

hmm - def double check your .local/share/gnome-shell/extensions/ folder - just in case you installed the extensions.gnome.org version or there's something up there.

e.g. make sure it's the correct symlink in there.

[jtaala]

I also can't find the console.debug line in the logs

You can change them (for testing) to a console.log line that should show up normally. Otherwise, you'll need to enable debug mode in looking glass with a GLib.log_set_debug_enabled(true) and then run the logs again (might want to grep to make it easier to see, e.g. journalctl -f /usr/bin/gnome-shell | grep paperwm.

[Lythenas]

Ah, that wasn't exactly the error, but apparently I had two clones of PaperWM and used the wrong one... My bad.

The PR seems to work in general (although sometimes there is a bit of a delay, I guess because of the timeout).

But I would say in general it is usable.

[jtaala]

Yeah, now I'm just trying to isolate and debug an issue (also can happen in release branch I think) where for multimonitors, if you go into overview, and windows for workspace one spill over to the second monitor... and you click a window (from workspace 1 but shown on monitor 2), then things can sometimes go a bit awry. Still trying to understand that one since I'm working in that area of code thought would try fix it as well.