Bug 482142 - drag in drop files in Google Chrome renders Chrome unusable
Summary: drag in drop files in Google Chrome renders Chrome unusable
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 6.0.4
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: qt6
: 483494 484491 486638 488113 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-03-01 12:17 UTC by Jetchko Jekov
Modified: 2024-06-26 16:41 UTC (History)
63 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jetchko Jekov 2024-03-01 12:17:06 UTC
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
Comment 1 Patrick Silva 2024-03-01 14:19:48 UTC
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
Comment 2 florian.flatscher 2024-03-09 13:13:26 UTC
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
Comment 3 florian.flatscher 2024-03-09 13:15:49 UTC
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
Comment 4 Ulrich Schreiner 2024-03-10 14:08:40 UTC
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.
Comment 5 simon+kde 2024-03-11 17:04:10 UTC
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
Comment 6 Hyuri 2024-03-13 16:29:37 UTC
This is happening in Plasma 5.27 as well (Kubuntu 23.10).
Comment 7 Riccardo 2024-03-14 11:47:44 UTC
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
Comment 8 ungoogled1 2024-03-18 16:31:23 UTC
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.
Comment 9 Nick Yamane 2024-03-18 16:48:30 UTC
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.
Comment 10 ungoogled1 2024-03-18 16:53:32 UTC
I just tried it again and this bug seems to be resolved for me in the new KDE 6.0.2
Comment 11 Patrick Silva 2024-03-18 16:56:20 UTC
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
Comment 12 ungoogled1 2024-03-18 16:57:42 UTC
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
Comment 13 Horváth Péter 2024-03-28 10:35:49 UTC
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
Comment 14 Riccardo 2024-03-29 10:59:08 UTC
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
Comment 15 hmnd 2024-04-21 01:46:34 UTC
(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
Comment 16 Eric Donkersloot 2024-04-23 19:05:30 UTC
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
Comment 17 duhdugg 2024-04-26 16:15:08 UTC
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
Comment 18 hexchain 2024-04-28 15:07:36 UTC
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.
Comment 19 Yaroslav Fedevych 2024-04-28 20:34:11 UTC
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.
Comment 20 mike cirioli 2024-04-30 12:07:06 UTC
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
Comment 21 Anya 2024-05-03 14:13:12 UTC
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
Comment 22 flex 2024-05-05 02:20:15 UTC
Chrome on wayland can reproduce this

Chrome version 124.0.6367.118 
Kwin 5.27.11
QT 6.7.0
Comment 23 thomas.steinborn 2024-05-05 09:05:07 UTC
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.
Comment 24 Yaroslav Fedevych 2024-05-05 15:16:46 UTC
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.
Comment 25 terranova 2024-05-09 15:49:26 UTC
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.
Comment 26 Jean-Francois Roy 2024-05-09 16:01:52 UTC
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.
Comment 27 Ted Parvu 2024-05-12 16:30:42 UTC
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
Comment 28 Ted Parvu 2024-05-12 16:38:42 UTC
(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
Comment 29 Ed Tomlinson 2024-05-12 16:45:16 UTC
No this is NOT a fix.   As mentioned above see:  https://issues.chromium.org/issues/336449364
Comment 30 Ted Parvu 2024-05-12 23:26:36 UTC
(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?
Comment 31 Ted Parvu 2024-05-13 01:08:15 UTC
Found a work-a-round that is working for me.

https://bbs.archlinux.org/viewtopic.php?pid=2166339#p2166339
Comment 32 Jean-Francois Roy 2024-05-13 04:00:15 UTC
(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.
Comment 33 Jakub 2024-05-13 10:19:03 UTC
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
Comment 34 terranova 2024-05-13 18:50:53 UTC
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();
```
Comment 35 Bastian Beischer 2024-05-15 11:50:06 UTC
@terranova indeed that works and I haven't noticed any regressions running this for a while.
Comment 36 Dinko 2024-05-15 14:55:35 UTC
I also can confirm that @terranova patch works on kwin 6.0.4 on arch and opensuse
Comment 37 terranova 2024-05-15 15:04:44 UTC
I have opened a merge request:
https://invent.kde.org/plasma/kwin/-/merge_requests/5730
Comment 38 Red 2024-05-15 20:55:24 UTC
(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
Comment 39 terranova 2024-05-15 21:43:27 UTC
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.
Comment 40 David Edmundson 2024-05-15 22:05:40 UTC
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.
Comment 41 David Edmundson 2024-05-15 22:16:26 UTC
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.
Comment 42 terranova 2024-05-15 22:18:53 UTC
Selecting text in the browser and dragging and releasing elsewhere in the browser was the most consistent repro for me.
Comment 43 David Edmundson 2024-05-15 22:26:59 UTC
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.
Comment 44 Bug Janitor Service 2024-05-15 22:39:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5733
Comment 45 Nate Graham 2024-05-15 23:03:33 UTC
*** Bug 483494 has been marked as a duplicate of this bug. ***
Comment 46 David Edmundson 2024-05-16 08:41:00 UTC
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
Comment 47 Nate Graham 2024-05-17 13:19:36 UTC
*** Bug 486638 has been marked as a duplicate of this bug. ***
Comment 48 Nate Graham 2024-05-17 13:20:36 UTC
*** Bug 484491 has been marked as a duplicate of this bug. ***
Comment 49 Shawn 2024-06-01 23:24:49 UTC
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.
Comment 50 Antonio Rojas 2024-06-06 16:26:51 UTC
*** Bug 488113 has been marked as a duplicate of this bug. ***
Comment 51 Hyuri 2024-06-08 00:50:23 UTC
To be clear, this was only fixed for Plasma 6+, not Plasma 5.27+, right?
Comment 52 flex 2024-06-10 04:25:02 UTC
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?