Bug 394772 - Some GTK apps temporarily lose scroll focus while desktop notification are shown
Summary: Some GTK apps temporarily lose scroll focus while desktop notification are shown
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: 5.12.5
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://gitlab.gnome.org/GNOME/gtk/is...
Keywords:
: 394982 408029 412701 420110 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-05-28 01:31 UTC by Eridani Rodríguez
Modified: 2020-11-04 02:31 UTC (History)
23 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.19.3


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eridani Rodríguez 2018-05-28 01:31:39 UTC
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
Comment 1 Kai Uwe Broulik 2018-05-28 13:55:14 UTC
I recall this being a GTK3 bug where you cannot scroll in apps that don't have focus. Correct, Martin?
Comment 2 Martin Flöser 2018-05-28 15:54:34 UTC
(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.
Comment 3 Kai Uwe Broulik 2018-05-28 17:29:07 UTC
The one about "Cannot scroll in Firefox window when it doesnt have focus"?
Comment 4 Kai Uwe Broulik 2018-06-04 07:43:21 UTC
*** Bug 394982 has been marked as a duplicate of this bug. ***
Comment 5 Matej Mrenica 2018-06-05 10:07:46 UTC
(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
Comment 6 Daniel Duris 2018-06-05 11:09:39 UTC
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.
Comment 7 Daniel Duris 2018-06-05 11:10:18 UTC
Sorry, the previous comment should read: "It *wasn't* happening two weeks ago. It is now"
Comment 8 Patrick Silva 2018-09-16 15:06:10 UTC
Bug persists in plasma 5.14 beta on Arch Linux.
Quod libet player and pamac package manager are affected.
Comment 9 Patrick Silva 2019-06-14 00:15:55 UTC
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
Comment 10 Brian 2019-08-14 18:13:30 UTC
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?
Comment 11 Matej Mrenica 2019-08-14 19:09:29 UTC
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.
Comment 12 Patrick Silva 2019-08-15 18:09:15 UTC
(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
Comment 13 David Edmundson 2019-08-15 20:45:03 UTC
@kbroulik you're thinking of 408029
Comment 14 David Edmundson 2019-08-15 22:34:06 UTC
It doesn't happen with GDK_CORE_DEVICE_EVENTS=1
Comment 15 Matej Mrenica 2019-08-16 07:40:05 UTC
(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.
Comment 16 David Edmundson 2019-08-16 09:27:58 UTC
>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.
Comment 17 Patrick Silva 2019-10-08 17:06:17 UTC
*** Bug 412701 has been marked as a duplicate of this bug. ***
Comment 18 Nate Graham 2020-04-02 14:47:02 UTC
*** Bug 408029 has been marked as a duplicate of this bug. ***
Comment 19 Nate Graham 2020-04-02 15:06:28 UTC
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.
Comment 20 Nate Graham 2020-04-15 18:12:56 UTC
*** Bug 420110 has been marked as a duplicate of this bug. ***
Comment 21 Nate Graham 2020-04-15 18:13:27 UTC
Yeah, nothing we can do here, sorry. :( GTK just needs to be fixed.
Comment 22 David Edmundson 2020-05-22 16:31:06 UTC
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.
Comment 23 Nate Graham 2020-05-22 16:44:34 UTC
Can confirm that unchecking that setting fixes the issue. How bizarre/heartening!
Comment 24 Martin Flöser 2020-05-22 17:32:32 UTC
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.
Comment 25 Nate Graham 2020-05-22 18:40:33 UTC
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.
Comment 26 Martin Flöser 2020-05-22 19:11:18 UTC
For unfocused windows a mouse grab is always installed. So that is probably the same issue.
Comment 27 Alex Fliker 2020-05-23 17:18:36 UTC
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...
Comment 28 Vlad Zahorodnii 2020-06-23 10:21:05 UTC
(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.
Comment 29 Vlad Zahorodnii 2020-06-23 10:58:34 UTC
Relevant merge request: https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/2140
Comment 30 Bug Janitor Service 2020-06-23 18:00:51 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/78
Comment 31 Nate Graham 2020-06-24 14:19:55 UTC
Just fixed! Thanks, Vlad!
Comment 32 QwertyChouskie 2020-07-27 19:48:16 UTC
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.
Comment 33 Vlad Zahorodnii 2020-07-28 07:19:55 UTC
(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.
Comment 34 Vlad Zahorodnii 2020-07-28 07:39:18 UTC
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
Comment 35 Nate Graham 2020-07-28 14:03:15 UTC
Thanks Vlad!