Overview: Some GTK applications lose focus when a desktop notification is displayed Tested and affected: - File-roller 3.16.5-0 - Synaptic 0.83 - Snapper GUI (master) - Meld 3.14.2 - Remarkable 1.87 Tested and not affected: - Gmusicbrowser - PlayOnLinux - Shotwell - GIMP Steps to Reproduce: 1) Play some music. 2) Open any of the listed programs and navigate to a window with enough content to get a scrollbar. 3) Scroll up and down while waiting for the track change notification. Actual Results: Focus is lost while the notification stays visible. Expected Results: Should be possible to keep scrolling like in most other programs. Build Date & Platform: Unsure & KDE neon 5.12 Additional Information: KDE Frameworks 5.46.0 Plasma 5.12.5 Qt 5.10.0 X Server 1.19.5 Proprietary nVidia drivers 390.59 GeForce GTX 1060
I recall this being a GTK3 bug where you cannot scroll in apps that don't have focus. Correct, Martin?
(In reply to Kai Uwe Broulik from comment #1) > I recall this being a GTK3 bug where you cannot scroll in apps that don't > have focus. Correct, Martin? I have never heard of this issue.
The one about "Cannot scroll in Firefox window when it doesnt have focus"?
*** Bug 394982 has been marked as a duplicate of this bug. ***
(In reply to Kai Uwe Broulik from comment #3) > The one about "Cannot scroll in Firefox window when it doesnt have focus"? It looks like a bug in gtk3 that only happens on Plasma
Must be a recent change in one of Gtk libraries. It was happening two weeks ago. It is now. I am on (K)Ubuntu 17.10.
Sorry, the previous comment should read: "It *wasn't* happening two weeks ago. It is now"
Bug persists in plasma 5.14 beta on Arch Linux. Quod libet player and pamac package manager are affected.
This issue persists with the new notifications system. Operating System: Arch Linux KDE Plasma Version: 5.16.0 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0 RC
I can confirm this issue affects me on the latest versions of plasma (even git), on arch and neon, and with (Wayland ... refer to 400987) (or) Xorg. https://bugs.kde.org/show_bug.cgi?id=400987 Might be related?
This can be also reproduced with gtk3-demo: 1. start gtk3-demo 2. test scrolling -> it should work 3. open anything on Plasma panel (app menu, applets - networks/sound/...) -> focus is taken and given to Panel 4. close app menu/applet by clicking it again 5. try to scroll in gtk3-demo -> you cannot, focus wasn't returned from Plasma panel back to the gtk app 6. Scrolling will be fixed ONLY after alt-tabbing back to the gtk app (clicking on anything anywhere doesn't fix this) Can someone check if focus is returned back after using Plasma panel? Also I am willing to test anything you come up with.
(In reply to mthw0 from comment #11) > This can be also reproduced with gtk3-demo: > > 1. start gtk3-demo > 2. test scrolling -> it should work > 3. open anything on Plasma panel (app menu, applets - networks/sound/...) -> > focus is taken and given to Panel > 4. close app menu/applet by clicking it again > 5. try to scroll in gtk3-demo -> you cannot, focus wasn't returned from > Plasma panel back to the gtk app > 6. Scrolling will be fixed ONLY after alt-tabbing back to the gtk app > (clicking on anything anywhere doesn't fix this) > > Can someone check if focus is returned back after using Plasma panel? Also I > am willing to test anything you come up with. I can reproduce this problem only on X11 session. Operating System: Arch Linux KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0
@kbroulik you're thinking of 408029
It doesn't happen with GDK_CORE_DEVICE_EVENTS=1
(In reply to David Edmundson from comment #14) > It doesn't happen with GDK_CORE_DEVICE_EVENTS=1 No, it does not, but: This is only a workaround not a fix This bug is only present in Plasma/Kwin This workaround disables some useful XInput2 functionality like "smooth scrolling" on touchpads... (In reply to David Edmundson from comment #13) > @kbroulik you're thinking of 408029 These two bugs seem to be caused by the same problem, and thus should be duplicates.
>This is only a workaround not a fix Of course, I'm adding it as a data point for debugging further, not suggesting anything else.
*** Bug 412701 has been marked as a duplicate of this bug. ***
*** Bug 408029 has been marked as a duplicate of this bug. ***
Yes, this is a known issue in GTK itself on X11: https://gitlab.gnome.org/GNOME/gtk/issues/558 It doesn't just affect Plasma; it seems to hit GNOME shell too. Sadly the GTK developers gave up on fixing it on X11. If there's no way we can work around it on the KWin side, then I guess this has to be RESOLVED UPSTREAM. :( Moving to KWin to find out.
*** Bug 420110 has been marked as a duplicate of this bug. ***
Yeah, nothing we can do here, sorry. :( GTK just needs to be fixed.
That duplicate report is about missing the first wheel event when it's replayed. This is about continued wheel events, and it shouldn't be being replayed. I put a lot of debug into GTK and have some notes: 1) It only happens when kwin is running, not fluxbox or picom 2) I built GTK, for every scroll click it's getting a leave event and an enter event - even though it shouldn't be losing focus at all. GTK resets cached scroll events on focus change which is why it has no impact. 3) Even more super super weird. *unchecking* "click raises active window" fixes this. That last one gives us something to check for.
Can confirm that unchecking that setting fixes the issue. How bizarre/heartening!
KWin holds a passive mouse grab. This is established in events.cpp in method X11Client::updateMouseGrab (https://cgit.kde.org/kwin.git/tree/events.cpp#n861 ). I assume this is the relevant piece of code especially as it checks for the clickRaise option. This piece of code is still using the xcore input grabs. My hope would be that changing to xinput2 grabs this would fix it. I had thought about that in the past when Krita complained about alt+click breaking things. If we changed the grabs to only operate on the pointer devices the scroll wheel should no longer be affected neither wacom devices.
FWIW unchecking that setting does fix the issue where scrolling in GTK3 windows (using a mouse wheel or touchpad) breaks when a notification arrives, but does not fix the case where scrolling in unfocused GTK3 windows using a mouse wheel has no effect/is broken. Scrolling with a touchpad in an inactive window still works.
For unfocused windows a mouse grab is always installed. So that is probably the same issue.
This issue drives me NUTS! It started after upgrading to 5.18. LibreOffice / Sublime / RawTherapee are the most notable apps for me which are affected. Firefox is not affected at all...
(In reply to David Edmundson from comment #22) > 1) It only happens when kwin is running, not fluxbox or picom Window managers such as fluxbox and openbox don't grab Button4 and Button5. (In reply to Martin Flöser from comment #24) > This piece of code is still using the xcore input grabs. My hope would be > that changing to xinput2 grabs this would fix it. I had thought about that This bug will present even after porting kwin to xi2.
Relevant merge request: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2140
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/78
Just fixed! Thanks, Vlad!
Any chance to also backport this fix to the 5.18 series? As 5.18 is what is in the current Ubuntu LTS, having the fix there would benefit many users.
(In reply to QwertyChouskie from comment #32) > Any chance to also backport this fix to the 5.18 series? As 5.18 is what is > in the current Ubuntu LTS, having the fix there would benefit many users. Oops, yeah, we need to backport the workaround to 5.18 as well.
Git commit 617adda2911e08cef70e110b3125e7d3f60498d1 by Vlad Zahorodnii. Committed on 28/07/2020 at 07:21. Pushed by vladz into branch 'Plasma/5.18'. [x11] Hold a passive grab on buttons only when needed Due to a bug in the XI2 protocol, clients have to reset scroll valuators on XI_Enter because the scroll valuators might have changed while the pointer was elsewhere. The XI_Enter event is usually sent when an input device enters the window, but it can also be generated by a passive grab. If an XI_Enter event has been generated by a passive grab, the client should not reset scroll valuators. Unfortunately, there is no any reliable way for the client to determine if an XI_Enter event has been sent in response to a deactivated passive grab. A correct fix for the scroll issues in GTK apps would involve changes in the XI2 protocol. As a work around, we can hold a passive grab only if the current mouse wheel action is either "Activate and scroll" or "Activate, raise, and scroll." FIXED-IN: 5.19.3 (cherry picked from commit ec5a0249e26acdf12677df535df3d3faa6a18b49) M +68 -45 events.cpp M +3 -0 options.h M +1 -0 x11client.cpp M +2 -2 x11client.h https://invent.kde.org/plasma/kwin/commit/617adda2911e08cef70e110b3125e7d3f60498d1
Thanks Vlad!