Bug 482142

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.

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

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();
```

@terranova indeed that works and I haven't noticed any regressions running this for a while.

I also can confirm that @terranova patch works on kwin 6.0.4 on arch and opensuse

I have opened a merge request:
https://invent.kde.org/plasma/kwin/-/merge_requests/5730

(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

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.

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.

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.

Selecting text in the browser and dragging and releasing elsewhere in the browser was the most consistent repro for me.

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.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5733

*** Bug 483494 has been marked as a duplicate of this bug. ***

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

*** Bug 486638 has been marked as a duplicate of this bug. ***

*** Bug 484491 has been marked as a duplicate of this bug. ***

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.

*** Bug 488113 has been marked as a duplicate of this bug. ***

To be clear, this was only fixed for Plasma 6+, not Plasma 5.27+, right?

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?