GNOME Bugzilla – Bug 750994
X11: First mouse wheel event ignored after right click or Alt+Tab or Win key press
Last modified: 2018-05-02 16:37:34 UTC
On X11, if you do a right mouse button click, the first mouse wheel event is ignored. The same happens when you press Alt+Tab, Win key or probably some other keys. Please see the attached video. This does not happen on Wayland. It happens only with gtk3 apps, tested with gedit and firefox (using gtk3 on Fedora 22). It does not happen with gtk2 apps (empathy, zim) or qt apps. Reproducer: 1. Open gedit, populate it with some text 2. Verify that scrolling works as expected 3. Do a right mouse click, either inside gedit, on its toolbar, or completely outside of its window, it doesn't matter 4. You can do some more right or left mouse button clicks to cancel any context menus, etc 5. Scroll up or down a single time (one notch) in gedit window - see that nothing happens 6. Try to scroll again - this time it scrolls properly I found this in Firefox, because I have a gesture mapped to right mouse click held + wheel up or down. And the first time I use this it never works, I have to repeat scrolling, which is quite confusing. gtk3-3.16.3-1.fc22.x86_64 gnome-shell-3.16.2-1.fc22.x86_64 libinput-0.17.0-2.fc22.x86_64 xorg-x11-drv-libinput-0.10.0-5.fc22.x86_64 Fedora 22
I can't attach the video, the size limits are too strict. It's available here: https://kparal.fedorapeople.org/bugs/gnome_750994.webm
Created attachment 305292 [details] list of installed packages
Here's a Firefox bug report where people seem to be affected by this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1226706
This is due to xi2 protocol deficiencies around valuators. I'm sure we have a bug with more of the backstory somewhere, but I can't find it right now.
(In reply to Matthias Clasen from comment #4) > This is due to xi2 protocol deficiencies around valuators. I'm sure we have > a bug with more of the backstory somewhere, but I can't find it right now. There's a more recent recap of this in https://bugzilla.gnome.org/show_bug.cgi?id=750870#c3 . I'm not really thrilled by the choices here, I guess we'll eventually have to go down the "XIQueryDevice on everything" path. Patch coming.
Created attachment 305934 [details] [review] x11: Query pointer devices' scroll valuators on toplevel enter events We used to "invalidate" scroll valuators, so the next scroll event could be used as the base for the next scroll deltas. This has the inconvenience that it invariably consumes the first event received after enter and, due to interactions with WM overeager passive button grabs, there's a possibility we don't scroll at all if we receive interleaved "smooth scroll" XI_Motion events and XI_Enter events (Normally triggered by regular scroll wheels in mice). In order to fix this, and at the expense of some sync-call overhead on XI_Enter events (one XIQueryDevice call per slave device), query the current scroll valuator state for all the slaves of the entered pointer, so we do know beforehand the right base values. If new devices are plugged while the pointer is on top of the client, the initialized scroll values will match the valuators'. https://bugzilla.gnome.org/show_bug.cgi?id=750994 https://bugzilla.gnome.org/show_bug.cgi?id=750870
Attachment 305934 [details] pushed as 77b8495 - x11: Query pointer devices' scroll valuators on toplevel enter events
This patch has been reverted as it broke a number of other scenarios, which brings again the behavior described in this bug. I'm reopening this bug, just to leave it dry up in bugzilla as a recipient for possible dups. It's not that I don't consider it a huge trait of smooth scrolling implementation in GTK+/X11, but at this point I consider nothing can be done anywhere in the stack to get rid of it, So I'll start considering this as "per design". So the options here are 1) Wait for wayland or 2) live with it, sorry for that.
That's unfortunate. Thank you for explanation. Hopefully Wayland it not that far away.
*** Bug 752636 has been marked as a duplicate of this bug. ***
*** Bug 752891 has been marked as a duplicate of this bug. ***
*** Bug 773578 has been marked as a duplicate of this bug. ***
Chromium faces this problem as well. See https://bugs.chromium.org/p/chromium/issues/detail?id=593453 The attempted solution was to use a heuristic to determine if a device has a mousewheel and to fall back to xinput1 for those devices. It seemed to work, but the heuristic is broken (it is wrong differently with both Xwayland and xorg-x11-drv-libinput). Does this solution seem viable for gtk if we can update the input drivers to report mousewheels directly and not rely on heuristics?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/558.