Drag and drop breaks mouse on Wayland

[liamhays]

Acknowledgements

• I have checked that there is no other issue describing the same or
  similar problem that I currently have, regardless if it has been
  closed or open.

• This bug affects Discord website.

• This issue is confirmed to be reproducible when WebCord is packaged
  on at least all three latest supported Electron major releases.

• This issue is reproducible in Chrome, Chromium or any
  Chromium-based browser, e.g Brave or Edge (please write in
  Additional Context which browser you have used if it is neither
  Chrome nor unmodified Chromium).

• There are no fixes done to master which resolves this issue.

• My issue describes one of the unstable and/or not fully implemented
  features.

• I have found a workaround to mitigate or temporarily fix this issue
  in affected releases (please write it in Additional context section
  below).

Operating System / Platform

🐧️ Linux

Operating system architecture

x64 (64-bit Intel/AMD)

Electron version

29.0.0

Application version

v4.8.0

Bug description

This may be a duplicate of #464.

If I run WebCord with --enable-features=UseOzonePlatform --ozone-platform=wayland to enable native Wayland support, then drag and drop a file into a chat, the file is successfully added to the Discord message box, but WebCord stops reacting to the mouse pointer: I can move the mouse pointer through the window but I cannot select anything in the window, including the menu bar. The window does however react to the keyboard: I can type in the message box, I can use shortcuts, and I can even press Alt to display the menu bar, but the pointer does not change shape on elements and the window does not respond to clicks. This does not happen if I run WebCord under X11 via XWayland.

Additional context

I am running Arch Linux with KDE Plasma 6.0.1 under Wayland on my laptop with an Intel Core i3-7100U (Intel HD Graphics 620) and no external graphics. WebCord is installed from https://aur.archlinux.org/packages/webcord-bin.

[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.