482142 2024-03-01 12:17:06 +0000 drag and drop files in Google Chrome renders Chrome unusable 2026-01-02 20:36:10 +0000 1 1 4 Plasma kwin Wayland drag-and-drop 6.0.4 Neon Linux RESOLVED FIXED https://bugs.kde.org/show_bug.cgi?id=483645 https://bugs.kde.org/show_bug.cgi?id=489212 qt6 NOR normal --- 1 jetchko.jekov kwin-bugs-null adamantgarth agurenko aneesaf1 anya.vanillagarden auxsvr bastian.beischer bugseforuns cardinalidiego cesarg9 cirioli.spam contact craig.finnegan daniel dapolinario david dinkonin dolphin-bugs-null d_debnath edtoml edu eric.donkersloot florian.flatscher frostynova grzegorz.alibozek hpeter1994 hyuri.pimentel jf jjaruszewski jon9097 jordan kde.org kde kde kdedev kotarf Landgraf132 m.kurz marek+kde marianpoltak marius.adrian.g Martin.Corley matthewnnewland me meirgoldstein06 msylwester nate nickdiego nplatis postix postnozet reverier.xu riccardo.varotto rm shawn smowtenshi strijbol.niko strong.drum0546 ted thomas.steinborn tinoucas tobyfox ulrich.schreiner ungoogled1 wingv5289 wk xaver.hugl yaroslav yoann.laissus https://invent.kde.org/plasma/kwin/-/commit/711c5bb43f2823766d5189dc8d567c8f4cec253c 6.1 0 oldest_to_newest 2293365 0 jetchko.jekov 2024-03-01 12:17:06 +0000 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 2293413 1 bugseforuns 2024-03-01 14:19:48 +0000 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 2297802 2 florian.flatscher 2024-03-09 13:13:26 +0000 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 2297803 3 florian.flatscher 2024-03-09 13:15:49 +0000 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 2298335 4 ulrich.schreiner 2024-03-10 14:08:40 +0000 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. 2299018 5 simon+kde 2024-03-11 17:04:10 +0000 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 2300213 6 hyuri.pimentel 2024-03-13 16:29:37 +0000 This is happening in Plasma 5.27 as well (Kubuntu 23.10). 2300687 7 riccardo.varotto 2024-03-14 11:47:44 +0000 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 2302574 8 ungoogled1 2024-03-18 16:31:23 +0000 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. 2302581 9 nickdiego 2024-03-18 16:48:30 +0000 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. 2302584 10 ungoogled1 2024-03-18 16:53:32 +0000 I just tried it again and this bug seems to be resolved for me in the new KDE 6.0.2 2302586 11 bugseforuns 2024-03-18 16:56:20 +0000 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 2302587 12 ungoogled1 2024-03-18 16:57:42 +0000 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 2306461 13 hpeter1994 2024-03-28 10:35:49 +0000 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 2306725 14 riccardo.varotto 2024-03-29 10:59:08 +0000 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 2313085 15 david 2024-04-21 01:46:34 +0000 (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 2313805 16 eric.donkersloot 2024-04-23 19:05:30 +0000 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 2314535 17 kde.org 2024-04-26 16:15:08 +0000 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 2314915 18 kde 2024-04-28 15:07:36 +0000 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. 2314960 19 yaroslav 2024-04-28 20:34:11 +0000 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. 2315312 20 cirioli.spam 2024-04-30 12:07:06 +0000 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 2316119 21 anya.vanillagarden 2024-05-03 14:13:12 +0000 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 2316576 22 frostynova 2024-05-05 02:20:15 +0000 Chrome on wayland can reproduce this Chrome version 124.0.6367.118 Kwin 5.27.11 QT 6.7.0 2316665 23 thomas.steinborn 2024-05-05 09:05:07 +0000 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. 2316721 24 yaroslav 2024-05-05 15:16:46 +0000 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. 2318573 25 matthewnnewland 2024-05-09 15:49:26 +0000 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. 2318574 26 jf 2024-05-09 16:01:52 +0000 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. 2319123 27 ted 2024-05-12 16:30:42 +0000 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 2319125 28 ted 2024-05-12 16:38:42 +0000 (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 2319126 29 edtoml 2024-05-12 16:45:16 +0000 No this is NOT a fix. As mentioned above see: https://issues.chromium.org/issues/336449364 2319182 30 ted 2024-05-12 23:26:36 +0000 (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? 2319186 31 ted 2024-05-13 01:08:15 +0000 Found a work-a-round that is working for me. https://bbs.archlinux.org/viewtopic.php?pid=2166339#p2166339 2319197 32 jf 2024-05-13 04:00:15 +0000 (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. 2319232 33 jjaruszewski 2024-05-13 10:19:03 +0000 As stated in Chromium issue: > 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. My understanding is that it's a kwin bug, though Chromium should minimally protect against this kind of compositor misbehavior and bugs instead of the taking assumptions and stop responding to input events (due to the dnd nested message loop to be kept running indefinitely). So maybe this is the kwin bug? Reproducible for me 2319359 34 matthewnnewland 2024-05-13 18:50:53 +0000 FWIW this patch seems to work for me KWin side (this is just based on the description of the KWin change in Chromium, I have no idea about regression potential): ``` diff --git a/src/wayland/seat.cpp b/src/wayland/seat.cpp index 9698156f6f..8cda1a94f4 100644 --- a/src/wayland/seat.cpp +++ b/src/wayland/seat.cpp @@ -290,6 +290,7 @@ void SeatInterfacePrivate::endDrag() Q_EMIT q->dragDropped(); dragTargetDevice->drop(); dragSource->dropPerformed(); + dragSource->dndFinished(); } else { dragSource->dropPerformed(); dragSource->dndCancelled(); ``` 2319782 35 bastian.beischer 2024-05-15 11:50:06 +0000 @terranova indeed that works and I haven't noticed any regressions running this for a while. 2319811 36 dinkonin 2024-05-15 14:55:35 +0000 I also can confirm that @terranova patch works on kwin 6.0.4 on arch and opensuse 2319815 37 matthewnnewland 2024-05-15 15:04:44 +0000 I have opened a merge request: https://invent.kde.org/plasma/kwin/-/merge_requests/5730 2319890 38 wingv5289 2024-05-15 20:55:24 +0000 (In reply to terranova from comment #37) > I have opened a merge request: > https://invent.kde.org/plasma/kwin/-/merge_requests/5730 This has been fixed by upstream: https://chromium-review.googlesource.com/c/chromium/src/+/5539621 2319902 39 matthewnnewland 2024-05-15 21:43:27 +0000 I will leave the patch up here in case it helps someone in the meantime but it looks unlikely to be merged. Hopefully the Chromium-side issue is enough. 2319904 40 kde 2024-05-15 22:05:40 +0000 FWIW, there's some notes on that MR. It's not quite right, we're still missing the cause. If there is a bug kwin side, it needs more investigation. Can someone give me steps to reproduce. I tried the ones above. I have both google-chrome-stable and google-chrome unstable and I'm forcing the wayland modes. I tried dragging a text file from my file manager into the address bar, and into a web app (Discord). That doesn't match the chrome comments, as I would have expected steps where Chrome is the source of the drag. 2319906 41 kde 2024-05-15 22:16:26 +0000 Got it based on my own comment: going to here https://www.w3schools.com/html/html5_draganddrop.asp and running the example freezes the mouse input but weirdly when you try to drag a second time. 2319909 42 matthewnnewland 2024-05-15 22:18:53 +0000 Selecting text in the browser and dragging and releasing elsewhere in the browser was the most consistent repro for me. 2319915 43 kde 2024-05-15 22:26:59 +0000 Chrome is doing something highly unusual. [2257948.361] wl_data_device@15.drop() [2257948.578] -> wl_data_offer@4278190082.destroy() [2257948.592] wl_data_source@58.dnd_drop_performed() We tell the target it's dropped, then it deletes the offer immediately. So it had a valid offer at the time of drop, but it doesn't finish that offer. 2319920 44 bug-janitor 2024-05-15 22:39:09 +0000 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5733 2319927 45 nate 2024-05-15 23:03:33 +0000 *** Bug 483494 has been marked as a duplicate of this bug. *** 2319970 46 kde 2024-05-16 08:41:00 +0000 Git commit 711c5bb43f2823766d5189dc8d567c8f4cec253c by David Edmundson. Committed on 16/05/2024 at 08:23. Pushed by davidedmundson into branch 'master'. wayland: send dndFinished to source if target fails to do so After receiving a drop a client should call data_offer.finish to tell the source it's done using the drop. A client could delete an offer after drop before calling finish. This can happen with misbehaving/buggy or malicious Wayland clients. A real case was found in the wild with Chromium, as described in the linked bug. In this situation we should let the source know the dnd is finished as there are no other transfers than can take place. We don't want to universally send this in all data offer destructors only, offers that are deleted post drop so the flag on the source is exposed. M +22 -2 src/wayland/abstract_data_source.h M +8 -1 src/wayland/dataoffer.cpp M +3 -12 src/wayland/datasource.cpp M +0 -3 src/wayland/datasource.h https://invent.kde.org/plasma/kwin/-/commit/711c5bb43f2823766d5189dc8d567c8f4cec253c 2320229 47 nate 2024-05-17 13:19:36 +0000 *** Bug 486638 has been marked as a duplicate of this bug. *** 2320231 48 nate 2024-05-17 13:20:36 +0000 *** Bug 484491 has been marked as a duplicate of this bug. *** 2323890 49 shawn 2024-06-01 23:24:49 +0000 kwin 6.0.5-2 was just released to Arch and seems to have fixed the issue. I can't make it crash when dragging something in Chromium, Brave etc. So nice to be able to switch the browser back to Wayland. 2325093 50 arojas 2024-06-06 16:26:51 +0000 *** Bug 488113 has been marked as a duplicate of this bug. *** 2325631 51 hyuri.pimentel 2024-06-08 00:50:23 +0000 To be clear, this was only fixed for Plasma 6+, not Plasma 5.27+, right? 2326047 52 frostynova 2024-06-10 04:25:02 +0000 Similarly concerned about this, Plasma 5.27 also has a large number of users affected.(In reply to Hyuri from comment #51) > To be clear, this was only fixed for Plasma 6+, not Plasma 5.27+, right? 2462937 53 edu 2025-10-18 17:15:33 +0000 Is this really fixed? I'm trying KDE Linux with plasma 6.6 and dragging text in chrome tab makes it stop responding to mouse events. Other tabs are unaffected. 2462955 54 david 2025-10-18 18:15:19 +0000 (In reply to edu from comment #53) > Is this really fixed? I'm trying KDE Linux with plasma 6.6 and dragging text > in chrome tab makes it stop responding to mouse events. Other tabs are > unaffected. Yeah, I don't think so. It's been happening to me occasionally too. 2463618 55 strong.drum0546 2025-10-21 16:47:11 +0000 Last two comments: thanks for bringing this up. I opened a new issue for this since I believe it is a different thing. See Bug 510876 2463917 56 xaver.hugl 2025-10-22 20:01:38 +0000 It's unlikely for that issue to be the exact same bug as this, let's track it only in the new bug report.