Bug 348270

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.

Thanks

Created attachment 92844 [details]
Example notification in the lower right corner that triggers the problem

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.

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.

Sorry.

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.

Can you perhaps install any other version of Firefox and try with that?

Perhaps related to focus settings?

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?

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.

Can you try upgrading/downgrading Firefox to confirm?

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.

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

This does not affect only FireFox, I can reproduce with GEdit too.

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).

Looks like gtk3 bug then (and as such should be closed here)?

I am also experiencing the problem now : Fedora 22, stock KDE 5.10.

I have this bug too. Fedora 22, KDE Frameworks 5.10.0

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.

dvratil confirmed that scrolling works using openbox (instead of kwin), reassigning to kwin

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?

firefox in fedora 22 (and newer) uses gtk3.  This is reproducible with other gtk3 apps besides firefox too (like gedit)

drop that - affects gtk3 clients, regardless of a kwin restart.

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 :-(

The btw. implies the question whether this is just a gtk3 bug and whether we actually want some clumsy workaround it if not.

Filed https://bugzilla.gnome.org/show_bug.cgi?id=750870 for investigation, might be https://bugzilla.gnome.org/show_bug.cgi?id=737726

Workaround:
-----------------
kwrite ~/.config/plasma-workspace/env/fix_gtk3.sh
----------------- snip --------------
#!/bin/sh
export GDK_CORE_DEVICE_EVENTS=1
----------------- /snip --------------
chmod +x ~/.config/plasma-workspace/env/fix_gtk3.sh


Background:
-----------------
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)

Solution:
------------
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.

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...).

Fixed in gtk3
https://git.gnome.org/browse/gtk%2B/commit/?id=77b8495

Just to say that i have to issue too, on Kubuntu 15.04 with backports.
Firefox 42.

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!).

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):
https://bugs.kde.org/show_bug.cgi?id=348270#c26

Exporting that in a gnome session should do as well.

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. :)

(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.

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

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.

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.

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.

The workaround I use is setting Xorg mouse driver to evdev.

/Allan

(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 :))