Drag and drop breaks mouse on Wayland about webcord

[liamhays]

I just noticed that Signal Desktop exhibits this same behavior if run under native Wayland, suggesting it might be an Electron issue.

[SpacingBat3]

(...) --enable-features=UseOzonePlatform (...)

FYI, this flag is redundant on WebCord. I think WebCord was adding it before with Wayland enabled and even if it wouldn't, it is believed recent Chromium builds are already enabling the use of ozone platform support. You should be aware, WebCord does as much as it is possible to tinker with Chromium command-line without re-launching or wrapping its own process, although some actions (like enabling Wayland) seem to be only possible before any process creation is made, otherwise it may lead to unexpected behaviour like crashes from my past experience when I was actually considering making WebCord switch to Wayland by the default (it's possibly too early to do that for now anyway, at least with Chromium still considering it somewhat experimental by itself or at least not using it by the default).

---

As of the issue, I might check it out later to see if I can reproduce it on Wayland on GNOME. Also I think #464 is not a duplicate (since it seems to explain the opposite situation: everything being fine with Wayland but not under XWayland) and I might also want to close it, given this issue ticket explaining the contrary situation to what was explained in #464 (that XWayland is functional but not Wayland, plus file being added to the message box).

Please explain if I understand correctly the bug you're experiencing and its reproducibility against different windowing systems.

[SpacingBat3]

I just noticed that Signal Desktop exhibits this same behavior if run under native Wayland, suggesting it might be an Electron issue.

I suspect this is more or less actually a bug within Chromium engine and it might not be present with different Electron builds. At worst it could be also introduced by Wayland implementation within DE, if something has changed around drag and drops (isn't Wayland spec still changing around some portal stuff?).

Also, you might find more info on that around other Electron/Chromium software, like VSCode:
microsoft/vscode#156723

I might also check if there's any upstream report made to Electron around this issue later.

[liamhays]

Yes, you understand correctly. Drag and drop leads to everything still working on XWayland, and causes the mouse to stop working on Wayland.

Because it still works perfectly on XWayland, there's no rush for a fix, especially if it's dependent on Wayland protocols that aren't finalized.

[liamhays]

For pure curiosity, I tested this on plain Chromium by dragging an image into the drop zone on https://dragdrop.com/test. Chromium exhibits the exact same behavior as WebCord: the mouse stops working on Wayland and keeps working on XWayland. This is on Chromium 123.0.6312.86 from the Arch repos.

Googling lead me to this Arch forum post, which links to this KDE issue. The newest comment on that bug report (from 3/29) suggests that this has been fixed in beta Chromium, currently version 124, which presumably will percolate down into Electron at some point.

I installed Chrome beta (not Chromium, it's not in the AUR, but I figure they're close enough for this test), and it does indeed seem to be fixed.

[liamhays]

This seems to be fixed in Chromium 123.0.6312.105.