Bug 348270 - Cannot scroll properly in GTK3 apps after focus switching
Summary: Cannot scroll properly in GTK3 apps after focus switching
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.3.1
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://bugzilla.redhat.com/show_bug....
: 348540 (view as bug list)
Depends on:
Reported: 2015-05-26 21:26 UTC by gero.kraus
Modified: 2020-11-04 02:18 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In:
thomas.luebking: Decision-Required+

Example notification in the lower right corner that triggers the problem (811.32 KB, image/png)
2015-05-27 08:42 UTC, gero.kraus

Note You need to log in before you can comment on or make changes to this bug.
Description gero.kraus 2015-05-26 21:26:20 UTC
Maybe also an issue on Firefox's site, but every time a notification (like a new song gets played or audio volume is changed) is shown, scrolling via mouse wheel isn't possible.
Navigation via Arrow keys stays possible, so it seems that Firefox just looses the focus for scrolling.
The Firefox version is 38.0.1.

Reproducible: Always

Steps to Reproduce:
1. Open a website in Firefox
2. Let plasma show a notification (Change the volume, skip a song, ...)
3. Scroll via mouse wheel in Firefox

Actual Results:  
Website doesn't scroll

Expected Results:  
Website should scroll
Comment 1 Martin Klapetek 2015-05-27 08:28:26 UTC
Thanks for the report.

Can you please attach a screenshot of the notification? Just so that we have an idea about which notification we're talking about.

Please attach it here by using the "Add an attachment" link below.

Comment 2 gero.kraus 2015-05-27 08:42:46 UTC
Created attachment 92844 [details]
Example notification in the lower right corner that triggers the problem
Comment 3 gero.kraus 2015-05-27 08:48:01 UTC
As I experienced it, the problem appears with every notification; I tried it with media playback, audio volume and smb4k notifications.
Also, I noticed, when Firefox loses focus and regains it (i.e. clicking into another window and back to Firefox), scrolling works again.
Comment 4 Martin Klapetek 2015-05-27 13:01:37 UTC
I've had three people test it, one of Fedora and noone can reproduce. Neither can I.

I'll leave this open for now but unless there's a reliable way to reproduce, we cannot investigate what's going on.

Comment 5 emschu 2015-05-29 08:07:10 UTC
I have the same issue and can reproduce it the same way as gero_reg_01 mentioned on Fedora 22 OS. Which data or log files do you need?
Thanks for your work.
Comment 6 Martin Klapetek 2015-05-29 08:44:09 UTC
Can you perhaps install any other version of Firefox and try with that?
Comment 7 Bhushan Shah 2015-05-30 03:07:19 UTC
Perhaps related to focus settings?
Comment 8 Martin Klapetek 2015-06-01 08:29:57 UTC
Unlikely; on X11 you can scoll inside any window even without it having focus.

If Firefox is the only window where this doesn't work, it's clearly a bug of its toolkit. If it doesn't work in any window, that's a bug not related to notifications then.

Can you please confirm that Firefox is the only application where this problem occurs?
Comment 9 gero.kraus 2015-06-01 08:39:43 UTC
Yes, Firefox is the only application where that happens.
Because you couldn't reproduce, it's probably a Fedora 22 / Firefox 38.0.1 related issue then.
Comment 10 Martin Klapetek 2015-06-01 08:40:35 UTC
Can you try upgrading/downgrading Firefox to confirm?
Comment 11 gero.kraus 2015-06-01 09:04:18 UTC
Unfortunately, in all Fedora repos (testing and rawhide) is only this version of Firefox. But I will keep you updated if a new version arrives.
Comment 12 Bhushan Shah 2015-06-01 10:32:39 UTC
*** Bug 348540 has been marked as a duplicate of this bug. ***
Comment 13 Daniel Vrátil 2015-06-01 11:25:33 UTC
This does not affect only FireFox, I can reproduce with GEdit too.
Comment 14 Daniel Vrátil 2015-06-01 11:29:04 UTC
Also note that it's not triggered only by notifications stealing focus from the window, but I can reproduce even when I move the focus manually to another window (or the shell).
Comment 15 Martin Klapetek 2015-06-01 11:30:30 UTC
Looks like gtk3 bug then (and as such should be closed here)?
Comment 16 Jean-Christophe Baptiste 2015-06-09 08:49:04 UTC
I am also experiencing the problem now : Fedora 22, stock KDE 5.10.
Comment 17 viktor 2015-06-09 08:50:46 UTC
I have this bug too. Fedora 22, KDE Frameworks 5.10.0
Comment 18 Martin Klapetek 2015-06-09 09:27:49 UTC
All the reports are coming from Fedora and Fedora only; I'm closing this as a downstream Fedora/GTK3 issue.

Please follow the upstream report at https://bugzilla.redhat.com/show_bug.cgi?id=1226465

We can't do anything with GTK here, sorry.
Comment 19 Rex Dieter 2015-06-12 14:37:15 UTC
dvratil confirmed that scrolling works using openbox (instead of kwin), reassigning to kwin
Comment 20 Thomas Lübking 2015-06-12 14:48:29 UTC
Firefox doesn't link gtk3, nor shows this problem here, can we please clarify whether this affects mozilla, gtk2 or gtk3 clients?

Does simply restarting kwin during the session ("kwin_x11 --replace &") change anything about the situation?
Comment 21 Rex Dieter 2015-06-12 14:51:00 UTC
firefox in fedora 22 (and newer) uses gtk3.  This is reproducible with other gtk3 apps besides firefox too (like gedit)
Comment 22 Thomas Lübking 2015-06-12 14:51:10 UTC
drop that - affects gtk3 clients, regardless of a kwin restart.
Comment 23 Thomas Lübking 2015-06-12 16:14:22 UTC
The pointer event gets replayed by kwin like to any other window.
Openbox does simply not passivley grab/replay wheel events.

=> We can probably workaround this (the passive grab is "only" used to either activate or activate & raise the window, so either we simply don't hold a passive grab and pass the scroll or release the passive grab with the first scroll that activates the window)

Unfortunately that won't exactly be a streamlined patch :-(
Comment 24 Thomas Lübking 2015-06-12 16:41:29 UTC
The btw. implies the question whether this is just a gtk3 bug and whether we actually want some clumsy workaround it if not.
Comment 25 Thomas Lübking 2015-06-12 17:06:48 UTC
Filed https://bugzilla.gnome.org/show_bug.cgi?id=750870 for investigation, might be https://bugzilla.gnome.org/show_bug.cgi?id=737726
Comment 26 Thomas Lübking 2015-06-13 12:25:33 UTC
kwrite ~/.config/plasma-workspace/env/fix_gtk3.sh
----------------- snip --------------
----------------- /snip --------------
chmod +x ~/.config/plasma-workspace/env/fix_gtk3.sh

gtk3 does (by default) no longer "really" support mousewheels, but only motion events and the implementation to translate motion events into wheel events has a fundamental glitch in that the first motion event after a crossing event is ignored.

This causes
a) activate a gtk3 window, leave it, enter it (with the pointer) and perform one single wheel click -=> no reaction (but subsequent wheels will work - until you leave/enter the window again)
b) total breakage of event replaying (the event is delivered to the actual window as well as the window holding the passive grab, so there's a crossing event for _each_ wheel event, each one is the first one after entering the window)

I tend to deem this a pure gtk3 bug - not only because it breaks event replaying but also because the users first wheel invocation is ignored.
I offered two strategies to improve the situation on the gtk3 side, one which should be doable but would only cope with event replaying (timer based heuristics) and one which would also cover the ignoring of the first wheel event (generate a "wheel-a-like" motion on first motion if a wheelbutton event happened before) - but I don't know how this fits gtk3's infrastructure.

Maintainers take, but from the currently available information, this is INVALID from my POV.
Comment 27 Martin Flöser 2015-06-13 15:30:03 UTC
Let's reevaluate the situation in lets say a month - if nothing is done on GTK side we might need to look into working it around.

Side-node fun fact: that seems to mean that all GTK3 applications won't take wheel events on XWayland, because as far as I have tested Xwayland applications, wheel events are emulated with good old core pointer buttons and not with xinput 2 events (clearly an xwayland bug, but nevertheless...).
Comment 28 Thomas Lübking 2015-07-01 19:55:37 UTC
Fixed in gtk3
Comment 29 warthogdj 2015-08-29 20:49:01 UTC
Just to say that i have to issue too, on Kubuntu 15.04 with backports.
Firefox 42.
Comment 30 Allan 2016-05-20 22:16:40 UTC
While I realise this has nothing to do with KDE. A workaround would be awesome as this GTK3 bug (Opera, pavucontrol..) is still here anno 2016 with gtk 3.20.4. When mouse leaves the gtk window and comes back - first scroll event is ignored. :-o

As unbelievable as it may sound - it even happens in pure Gnome..
- Defective by design nearly on par with scrollbar snapback in Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=377191 (Gnome folks tried to implement this too, once.. Malice I say.. Malice!).
Comment 31 Thomas Lübking 2016-05-21 07:33:58 UTC
It happens (again) because the fixing patch in gtk was reverted, see https://bugzilla.gnome.org/show_bug.cgi?id=750994#c8

Workaround (deactiviating the breoken touch/scroll fake-a-round in gtk):

Exporting that in a gnome session should do as well.
Comment 32 Allan 2016-05-21 09:44:58 UTC
Hm, that workaround is being set here and working for the few gtk3 apps i just tested, but isn't doing the trick for Opera, even launched from a gnome-terminal for testing after confirming the env is set with echo $GDK_CORE_DEVICE_EVENTS returning 1 in that same terminal.

Ideas are very welcome. :)
Comment 33 Allan 2016-05-31 08:49:54 UTC
(In reply to Allan from comment #32)
> Hm, that workaround is being set here and working for the few gtk3 apps i
> just tested, but isn't doing the trick for Opera, even launched from a
> gnome-terminal for testing after confirming the env is set with echo
> $GDK_CORE_DEVICE_EVENTS returning 1 in that same terminal.
> Ideas are very welcome. :)

Apparently it also a bug in the current Opera (stable) separately.
Opera (beta) behaves fine.
Comment 34 Sebastian Krzyszkowiak 2016-09-24 22:19:35 UTC
This bug breaks touchpad smooth scrolling (using XInput 2.1 events) on Firefox when its window gets deactivated :( It kinda works, but it's very painful to use (fortunately getting focus back fixes it, so it's just an annoyance).

Should it stay "RESOLVED UPSTREAM" when GTK+ patch has been reverted and it's still broken to this day? Maybe it should be workarounded in KWin after all?

GDK_CORE_DEVICE_EVENTS is not an acceptable workaround, as it turns off smooth scrolling completely, and as much as I don't care about it in other GTK+ apps, Firefox is definitely one where I do care ;)
Comment 35 Martin Flöser 2016-10-04 07:42:04 UTC
Sorry but we don't have the manpower to work around issues in GTK in our software. Please raise the concern again on GTK level.
Comment 36 Sebastian Krzyszkowiak 2018-02-07 02:35:14 UTC
I have just noticed this behavior (unreliable touchpad scrolling in unfocused window) with editor in Qt Creator 4.5. I have tried it on Metacity and it doesn't happen there, so not sure if I should report here to KWin or to Qt Creator.
Comment 37 Ali Molaei 2018-02-14 17:58:33 UTC
I still have this issue on plasma 5.12.1 on Arch Linux

(1) Open Libreoffice Writer or any gtk application (caja, pluma,...) and do something in it. Observe the scroll wheel works.
(2) Click on the time in the Plasma panel to bring up the calendar, then minimize it by clicking on the time again. (It's important that you click on the time to minimize, rather than elsewhere on the screen, or this is less reproducible for some reason.)
(3) Go back to Libreoffice Writer and note the scroll wheel no longer works.
(4) Go into another application and use the scroll wheel in it. Observe it works fine.
(5) Go back to Libreoffice Writer and note the scroll wheel works again.
Comment 38 Allan 2018-02-14 18:08:30 UTC
The workaround I use is setting Xorg mouse driver to evdev.

Comment 39 Ali Molaei 2018-02-14 19:00:14 UTC
(In reply to Allan from comment #38)
> The workaround I use is setting Xorg mouse driver to evdev.
> /Allan

I tried that, even with evdev, the problem is there, and also my touchpad is not working with evdev :))