Dragging a file from Dolphin to Google Chrome renders Chrome unusable. Mouse clicks are not accepted anymore by Chrome. Keyboard work though. This started after the plasma 6 upgrade. SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.5.0-21-generic (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-1065G7 CPU @ 1.30GHz Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® Iris® Plus Graphics Manufacturer: Dell Inc. Product Name: Inspiron 14 5401
Can reproduce by dragging a .png file to Vivaldi browser running natively on Wayland. Operating System: Arch Linux KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Graphics Platform: Wayland
Reproducible on Fedora 39 for: Google Chrome Version 122.0.6261.111 (Official Build) (64-bit) Google Chrome (unsable) Version 124.0.6342.3 (Official Build) dev (64-bit) Chromium Version 122.0.6261.69 (Official Build) Fedora Project (64-bit) Interestingly, in chromium, the window becomes responsive/clickable again after I move the dropped file to another directory using drag & drop. To reproduce: 1) Open Chromium 2) Create a new empty Text-File on Desktop 3) Open Dolphin (Downloads folder) 4) Drag Text-File onto Chromium
Reproducible on Fedora 39 for: Google Chrome Version 122.0.6261.111 (Official Build) (64-bit) Google Chrome (unsable) Version 124.0.6342.3 (Official Build) dev (64-bit) Chromium Version 122.0.6261.69 (Official Build) Fedora Project (64-bit) Interestingly, in chromium, the window becomes responsive/clickable again after I move the dropped file to another directory using drag & drop. To reproduce: 1) Open Chromium 2) Create a new empty Text-File on Desktop 3) Open Dolphin (Downloads folder) 4) Drag Text-File onto Chromium -> Chromium becomes unresponsive/unclickable 5) Move the Text-File from Desktop to Dolphins Downloads folder using drag & drop -> Chromium becomes responsive/clickable again
Drag/Drop inside the apps also do not work. So drag/drop a link in chrome to the tab-Bar to open it does not work. Same happens with VSCode, so it looks like the bug appears with electron-based apps. workaround: dot NOT start apps with --enable-features=UseOzonePlatform --ozone-platform=wayland so they run as X11 apps. then everything works. you can check with kwin-debug-console='qdbus org.kde.KWin /KWin org.kde.KWin.showDebugConsole' if the electron-app (chrome, vscode) run native wayland -> drag/drops does not work. if they run as X11, everythings fine.
Reproducable on Gentoo. Draging & droping a file from Dolphin to Chrome makes Chrome no longer accept mouse inputs, but keyboard input still works. The same issue also appears when draging a screenshot from Spectactle to Chrome (e.g. to a Jira Issue). SOFTWARE/OS VERSIONS Operating System: Gentoo KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.7.4 (gentoo-sources) Graphics Platform: Wayland Processors: AMD Ryzen 9 PRO 6950H Memory: 31.1 GiB of RAM Graphics Processor: AMD 6500M/680M Hybrid Manufacturer: Lenovo Product Name: Z16 gen1
This is happening in Plasma 5.27 as well (Kubuntu 23.10).
Reproducible on Neon User Edition and Unstable 6.0.2 SOFTWARE/OS VERSIONS Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Graphics Platform: Wayland Chrome, Microsoft Edge (stable and beta): --enable-features=UseOzonePlatform --ozone-platform=wayland
In plasma-5 there was already a bug with chrome Wayland where it would randomly get stuck into dragging events and ignore further pointer events. This was partially fixed in the latest dev build https://chromiumdash.appspot.com/commit/d6bdbc12fabc1bfa1a17aca5c47afee6e17824fb In plasma-6 there where some regressions that are not fixed with the patch above: - dragging text from a page or the url bar to a new tab or bookmark does not work - dragging file from filemanager and dropping it on the browser makes it unresponsive to further mouse events which are tracked by the chromium team under https://issues.chromium.org/issues/329703410 dupe with video: https://issues.chromium.org/issues/327605550 Although they suggest in these issues thats a kwin/plasma-6 issue.
I've also documented other observations that may indicate other KWin bugs, or even underspecified behaviors/cases that must be addressed at the protocol level instead, at https://notes.nickdiego.dev/chromium/wayland-events-during-drag#KWin.
I just tried it again and this bug seems to be resolved for me in the new KDE 6.0.2
The bug persists with Chromium and Vivaldi on my system. Operating System: Arch Linux KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Graphics Platform: Wayland
Looking at my earlier message: 1. dragging text from a page or the url bar to a new tab or bookmark does not work 2. dragging file from filemanager and dropping it on the browser makes it unresponsive to further mouse events Bug 1 was fixed with kde 6.0.2 Bug 2 is still an issue
Dragging from file manager to Chrome indeed disables mouse actions. But if you drag a file into the window again, without dropping it , then mouse can be used again. Operating System: Arch Linux KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Graphics Platform: Wayland
It seems the problem is no more present on latest beta versions of chrome and ms-edge. KDE Plasma Version: 6.0.3 Graphics Platform: Wayland
(In reply to Riccardo from comment #14) > It seems the problem is no more present on latest beta versions of chrome > and ms-edge. I am still able to reproduce this on Chrome v126 + KDE Plasma 6.0.4 + NVIDIA
Unfortunately, this bug is still not fixed. I can reproduce it as well. Operating System: openSUSE Tumbleweed 20240419 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-1-default (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31,2 GiB of RAM Graphics Processor: AMD Radeon RX 6800 XT Manufacturer: ASUS
I am also seeing this issue. Accidental click drag on a link also causes it and leads to eventual browser crash. Reproducible on the Arch chromium package, brave-bin from the AUR, google-chrome-bin from the AUR, and ungoogled-chromium from flathub. Operating System: Arch Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.6.28-1-lts (64-bit) Graphics Platform: Wayland
I suspect there are multiple issues. The fix for https://issues.chromium.org/issues/329703410 has already landed in 124 (stable) and 125 (dev), but apparently, people are still seeing a similar issue. Filed https://issues.chromium.org/issues/336449364 for their awareness.
I have whatever the very latest Fedora 40 + updates has, and it's happening regardless whether Chrome is launched as a pure Wayland or an X11 client (!). Any accidental dragging gesture at all (usually I'm butterfingering the touchpad, or accidentally place a finger on the touchpad just as I'm making a left click) makes left click stop working. What also stops working is trying to invoke the main menu via keyboard shortcuts — Alt+F, for example. If I persist in left-clicking long enough, Chrome will eventually crash. The funniest thing is that I remember the bug being there before, and in some 5.2x version of Plasma it got fixed. Now it looks like a regression.
chrome Version 124.0.6367.91 (Official Build) (64-bit) on kwin 6.04 - I can reproduce this issue by simply dragging any page element in chrome. The issue is present for both wayland and x11
Can reproduce this with Chromium and Discord when they're running with --enable-features=UseOzonePlatform --ozone-platform=wayland. When attempting to drag and drop a file from Dolphin to Discord or Chromium the mouse cursor changes to the red stop sign thing and the file isn't dropped. It works without the arguments, running in Xwayland. Operating System: EndeavourOS KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-arch1-1 (64-bit) Graphics Platform: Wayland
Chrome on wayland can reproduce this Chrome version 124.0.6367.118 Kwin 5.27.11 QT 6.7.0
See the corresponding Chromium bug https://issues.chromium.org/issues/336449364#comment12 Copying from the comment: There seems to have been some recent change in Kwin which has caused it to no longer send wl_data_source.{dnd_finished,cancelled} after wl_data_source.dnd_drop_performed in these cases described in the repro steps.
Can we be sure that it's kwin as such and not, say, Qt itself? There's so many moving parts that thinking of trying to bisect it all is filling me with dread.
Just wanted to add that I have the same issue on Arch Linux, KDE 6.0.4. Hopefully either KWin or Chrome can come to a resolution soon—I may take a crack at trying to debug myself from the KWin side but I don't know enough about Wayland or the KDE codebase to be that useful yet.
We ideally need a solution in KWin because other applications based on Chromium are also affected and those tend to be on much slower upgrade cycles. Anything Electron (Discord, Slack, VS Code) are affected.
Reproducible by trying to drag and drop anything in Vivaldi. Arch Linux plasma-desktop 6.0.4-1 wayland 1.22.0-1 additionally I get this clue.... > 12/100737.466353:ERROR:wayland_data_drag_controller.cc(147)] Invalid state when trying to start drag. source=kMouse
(In reply to Ted Parvu from comment #27) > Reproducible by trying to drag and drop anything in Vivaldi. > > Arch Linux > plasma-desktop 6.0.4-1 > wayland 1.22.0-1 > > additionally I get this clue.... > > > 12/100737.466353:ERROR:wayland_data_drag_controller.cc(147)] Invalid state when trying to start drag. source=kMouse Looks like this was fixed https://chromium.googlesource.com/chromium/src/+/b3319430c1155a1716b441f225ef93f16493b5cb
No this is NOT a fix. As mentioned above see: https://issues.chromium.org/issues/336449364
(In reply to Ed Tomlinson from comment #29) > No this is NOT a fix. As mentioned above see: > https://issues.chromium.org/issues/336449364 So, where is this bug? It seems to be on all Chromium based browsers.... but that the bug is really in KWin?
Found a work-a-round that is working for me. https://bbs.archlinux.org/viewtopic.php?pid=2166339#p2166339
(In reply to Ted Parvu from comment #31) > Found a work-a-round that is working for me. > > https://bbs.archlinux.org/viewtopic.php?pid=2166339#p2166339 Completely disabling drag and drop is a pretty hard workaround to swallow and breaks a number of web apps that rely on it. I too am frustrated when I accidentally soft-lock Chrome, but this workaround should not lessen efforts to fix kwin.