Wheel scrolling periodically stops working with XInput2
Categories
(Core :: Widget: Gtk, defect, P3)
Tracking
()
People
(Reporter: botond, Assigned: stransky)
References
(Blocks 1 open bug)
Details
(Whiteboard: tpi:+)
Attachments
(1 file)
1.33 KB,
patch
|
Details | Diff | Splinter Review |
I'm trying the GTK3 build of Firefox and I'm running into an issue where wheel scrolling sometimes stops working. I haven't been able to nail down STR for this issue, but I'll be on the lookout for some. When this happens, it usually starts working again after a while (several seconds elapsing and/or various UI interactions, not sure exactly what resolves it).
Comment 1•9 years ago
|
||
I tried the GTK3 build today and wheel scrolling does not work at all.
Comment 2•9 years ago
|
||
I got repeating assertion log like: [Parent 27896] ###!!! ASSERTION: deltaX or deltaY must be non-zero: 'wheelEvent.deltaX || wheelEvent.deltaY', file /home/kanru/mozilla/gecko/widget/gtk/nsWindow.cpp, line 3063 [Parent 27896] ###!!! ASSERTION: deltaX or deltaY must be non-zero: 'wheelEvent.deltaX || wheelEvent.deltaY', file /home/kanru/mozilla/gecko/widget/gtk/nsWindow.cpp, line 3063 [Parent 27896] ###!!! ASSERTION: deltaX or deltaY must be non-zero: 'wheelEvent.deltaX || wheelEvent.deltaY', file /home/kanru/mozilla/gecko/widget/gtk/nsWindow.cpp, line 3063 [Parent 27896] ###!!! ASSERTION: deltaX or deltaY must be non-zero: 'wheelEvent.deltaX || wheelEvent.deltaY', file /home/kanru/mozilla/gecko/widget/gtk/nsWindow.cpp, line 3063 [Parent 27896] ###!!! ASSERTION: deltaX or deltaY must be non-zero: 'wheelEvent.deltaX || wheelEvent.deltaY', file /home/kanru/mozilla/gecko/widget/gtk/nsWindow.cpp, line 3063
Reporter | ||
Comment 3•9 years ago
|
||
For the issue I'm experiencing, Andrew and I discovered that it happens when the Firefox window loses the focus, due to e.g. a system notification coming up. Explicitly focusing elsewhere and then back on the Firefox window restores the ability to wheel scroll.
Comment 4•9 years ago
|
||
This was fixed in upstream GTK; see https://git.gnome.org/browse/gtk%2B/commit/?id=77b8495 For now, you may want to manually force legacy Xlib scroll events by setting the environment variable GDK_CORE_DEVICE_EVENTS=1.
And this was later unfixed, because the fix was causing even worse issues (moose wheel going backwards, etc) https://git.gnome.org/browse/gtk+/commit/?id=72bfb40ccf746f743d9818f9dbecf2820f4557ba
Comment 6•9 years ago
|
||
GDK_CORE_DEVICE_EVENTS=1 works for me
Comment 7•9 years ago
|
||
[Tracking Requested - why for this release]: Jarring behaviour that we should fix before release.
I can confirm GDK_CORE_DEVICE_EVENTS=1 also fixes the issue for me. Maybe this could be set automatically by firefox?
Comment 9•9 years ago
|
||
(In reply to AnAkkk from comment #8) > I can confirm GDK_CORE_DEVICE_EVENTS=1 also fixes the issue for me. Maybe > this could be set automatically by firefox? I don't think we want to do this, as it disables XInput2 support entirely (no smooth trackpad scrolling, no touch, etc).
Comment 10•9 years ago
|
||
Is this a regression? Tracking for 42 because affects usability, we should fix broken wheel scrolling before release.
Comment 11•9 years ago
|
||
See https://bugzilla.gnome.org/show_bug.cgi?id=750994 and https://bugzilla.gnome.org/show_bug.cgi?id=750870 It actually works if you focus somewhere else and focus back in the firefox window. On KDE it just needs to minimize/maximize the firefox window.
Reporter | ||
Comment 12•9 years ago
|
||
This is a regression caused by the switch from GTK2 to GTK3. I think it should block the switch.
Reporter | ||
Updated•9 years ago
|
Comment 13•9 years ago
|
||
To clarify, this bug is not specific to Firefox- from my understanding, it affects all GTK3 apps that listen to GDK_SCROLL_SMOOTH under certain non-GNOME window managers (I only know of KWin being affected). If this situation is widespread, we may want to consider ignoring GDK_SCROLL_SMOOTH events and just listening to legacy events by default. Karl, what do you think about blocking smooth scroll events by a pref? We could default it to off until the upstream situation is better. Alternatively, perhaps we could use $XDG_CURRENT_DESKTOP to 'blacklist' KWin or any other WM with aggressive pointer grabs.
Updated•9 years ago
|
Comment 14•9 years ago
|
||
I can reproduce consistently in kwin on inactive windows with Click to Focus policy and Inactive Inner Window Wheel behavior configured to only Scroll. With Click to Focus and inactive inner window wheel behavior configured for Activate & Scroll, or with Focus Follows Mouse, the behavior seems to only reproduce when "Click raises active window" is selected. Then, even the focused window will not scroll unless it has the last window frame clicked. The issue is not present when scrolling with my touch pad. (In reply to Andrew Comminos [:acomminos] from comment #13) > Karl, what do you think about blocking smooth scroll events by a pref? We > could default it to off until the upstream situation is better. Do we have the option to do something different for mouse-wheel mice from what we do for touch pads or can we only choose between core or xi2 events for the whole process? I don't know that we can expect anything from upstream soon given the "1) Wait for wayland or 2) live with it" comment, unless we propose a fix. It's tough to decide what to choose for default because many people like the smooth scrolling, but this bug could be quite in the face of a number of people. > Alternatively, perhaps we could use $XDG_CURRENT_DESKTOP to 'blacklist' KWin > or any other WM with aggressive pointer grabs. That's also tricky because it also depends on the configuration, and the devices used. FWIW I think this is reasonable WM behavior, but I'd guess it is possible for WMs to work around. Given all GTK apps are affected by what I would consider a GDK bug, GDK_CORE_DEVICE_EVENTS=1 seems the best pref to set for those affected. Leave and event events don't have a timestamp afaik, so that's not useful for a fix though examining the events. If we can know which devices generate motion events with real valuators and which are just wheel button events, then the prognosis for a fix along those lines might be better. If this can be fixed upstream the a pref defaulting to off for older versions would seem appropriate. Can we make that decision late or do we need to know when opening the GDK display? If this is not fixed upstream, then the best solution is not clear to me.
Comment 15•9 years ago
|
||
(In reply to Kan-Ru Chen [:kanru] from comment #1) > I tried the GTK3 build today and wheel scrolling does not work at all. Others have reported this as not working only in certain situations. Can you describe your window manager, please?
Comment 16•9 years ago
|
||
(In reply to Karl Tomlinson (ni?:karlt) from comment #15) > (In reply to Kan-Ru Chen [:kanru] from comment #1) > > I tried the GTK3 build today and wheel scrolling does not work at all. > > Others have reported this as not working only in certain situations. > Can you describe your window manager, please? It's stumpwm, a non-reparenting tiling window manager. The only response from firefox while scrolling the wheel are the assertions.
Comment 17•9 years ago
|
||
(In reply to Andrew Comminos [:acomminos] from comment #13) > Karl, what do you think about blocking smooth scroll events by a pref? We > could default it to off until the upstream situation is better. I think that is the best interim solution until we can think of something better, as otherwise this is a fairly significant regression from GTK2.
Comment 18•9 years ago
|
||
I've noticed it happen on Ubuntu 15.04 when: 1. Switching windows. 2. Clicking middlemouse/rightmouse anywhere. 3. Switching between tabs with Ctrl+Tab (browser.ctrlTab.previews = true). 4. Clicking on the draggable titlebar/menubar/tabbar. It makes the browser feel unresponsive which is not pleasant.
Comment 20•9 years ago
|
||
This patch should help with some pain regarding scroll events with empty deltas- we ignore them, allowing us to safely fallback to using legacy events as we skip setting the last recorded event time. This works around the issue with the first scroll event on a window after refocus being ignored. Thanks!
Comment 21•9 years ago
|
||
Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2b9fa4b8c34a
Updated•9 years ago
|
Comment 22•9 years ago
|
||
Comment on attachment 8655306 [details] [diff] [review] Ignore GDK_SCROLL_SMOOTH events with empty deltas. >+ // Ignore the event if it has empty deltas- this can happen for the >+ // first scroll event on a window (see bug 1182700). In that case, we >+ // can fallback to legacy events. I like the idea, but please indicate that it is a bug (https://bugzilla.gnome.org/show_bug.cgi?id=726878) that allows us to fall back to legacy events. Fortunately we always have native windows now, but that bug may be fixed at some point. Perhaps it won't be before https://bugzilla.gnome.org/show_bug.cgi?id=750870 is fixed. AFAICS returning FALSE from the signal handler won't give us the legacy event, so we can't depend on that. I guess this is likely to sometimes introduce an initial jump for devices that do support fine smooth increments (GDK_SOURCE_TOUCHSCREEN and GDK_SOURCE_TOUCHPAD, I assume). Would it make sense to add the workaround only for other devices?
Comment 23•9 years ago
|
||
> I guess this is likely to sometimes introduce an initial jump for devices that
> do support fine smooth increments (GDK_SOURCE_TOUCHSCREEN and
> GDK_SOURCE_TOUCHPAD, I assume). Would it make sense to add the workaround only for other devices?
Possibly. IIRC, touchpad events will only synthesize a legacy event when sufficient scroll deltas have been accumulated. If the user scrolled enough in one event to produce a legacy scroll event, we should probably scroll anyway, otherwise we're providing a faux 'resistance' when the user starts scrolling.
Comment 24•9 years ago
|
||
(In reply to Andrew Comminos [:acomminos] from comment #23) > IIRC, touchpad events will only synthesize a legacy event when > sufficient scroll deltas have been accumulated. If the user scrolled enough > in one event to produce a legacy scroll event, we should probably scroll > anyway, otherwise we're providing a faux 'resistance' when the user starts > scrolling. I'm assuming that accumulated deltas may tick over a threshold at any point. Unless there's some kind of test of significant recent activity before the threshold, I guess the legacy event is delivered when the valuators tick past certain pre-defined positions. I'm also assuming that if the user has scrolled a large distance, that we will get several events from these devices, and so the cost of missing one event will be less than that of having the potential for triggering a large scroll at seemingly random points.
Comment 25•9 years ago
|
||
[Tracking Requested - why for this release]: AFAIK, we disabled GTK3 in beta 42, so this is not affected now. 43 and 44 are affected and this is pretty annoying when you are used to the mouse wheel for scrolling, so nominating for those.
Updated•9 years ago
|
Comment 26•9 years ago
|
||
Tracking for Nightly 44 because this has potential user impact, is a regression, and it would be good to get this fixed.
Comment 27•9 years ago
|
||
I just noticed I can no longer reproduce this bug in 43 or 44.
Comment 28•9 years ago
|
||
Karl, or Kairo, can you still reproduce this or might it be fixed now?
Comment 29•9 years ago
|
||
Ah, nevermind, looks like this was disabled in 43 as well, see https://bugzilla.mozilla.org/show_bug.cgi?id=1170342#c31. Kestrel, thanks for the report!
Comment 30•9 years ago
|
||
XInput2 was disabled in bug 1170342#c17 and bug 1170342#c31 to work around this and other problems. It is now only a problem if MOZ_USE_XINPUT2=1 is in the environment, but that is a debugging / use-at-your-own-risk variable so we don't need to track this for releases.
Comment 32•8 years ago
|
||
works for me on Ubuntu 16.04 with Nightly 51.0a1, 20160823030224
Comment 33•8 years ago
|
||
We'll still need to work around this for bug 1207700.
Updated•8 years ago
|
Updated•8 years ago
|
Comment 36•7 years ago
|
||
I can reproduce this consistently in Firefox 56 and 57, setting MOZ_USE_XINPUT2=1 while using i3-wm configured to focuss the window instantly as soon as it's under the cursor. However, only the very first scroll event after the window is focussed is lost, so perhaps it's a slightly different bug to this one. Chromium have an identical bug here already fixed and with some interesting patches: https://bugs.chromium.org/p/chromium/issues/detail?id=593453. I would really love this to be fixed, as I love being able to scroll accurately and smoothly using two-finger scroll on my touchpad, but that requires enabling xinput2 which uncovers this bug. (It's specially annoying with the patch in bug 1285812 applied, since it's a lot more noticeable as a missing change)
note that it seems to me that proper touchscreen operation requires MOZ_USE_XINPUT2=1 and proper focus requires MOZ_USE_XINPUT2=0 (still the case in Fx 59)
Assignee | ||
Comment 38•6 years ago
|
||
(In reply to Chris Hobbs from comment #36) > I can reproduce this consistently in Firefox 56 and 57, setting > MOZ_USE_XINPUT2=1 while using i3-wm configured to focuss the window > instantly as soon as it's under the cursor. However, only the very first > scroll event after the window is focussed is lost, so perhaps it's a > slightly different bug to this one. Chromium have an identical bug here > already fixed and with some interesting patches: > https://bugs.chromium.org/p/chromium/issues/detail?id=593453. > > I would really love this to be fixed, as I love being able to scroll > accurately and smoothly using two-finger scroll on my touchpad, but that > requires enabling xinput2 which uncovers this bug. (It's specially annoying > with the patch in bug 1285812 applied, since it's a lot more noticeable as a > missing change) Can you please try to reproduce on latest trunk with: $MOZ_USE_XINPUT2=1 MOZ_GTK_TITLEBAR_DECORATION="client" ./firefox the MOZ_GTK_TITLEBAR_DECORATION="client" forces CSD mode which means the input events are not attached to toplevel window.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
I still lose focus personally with that test: ~ $ MOZ_USE_XINPUT2=1 MOZ_GTK_TITLEBAR_DECORATION="client" firefox-nightly ~ $ sleep 1.5 ; notify-send test <scroll scroll on webpage> <notification takes focus and interrupts> (this works fine without MOZ_USE_XINPUT2) BuildID: 20180119103852 (in case its not yet in nightly let me know and ill retry with tomorrow's build)
Comment 40•6 years ago
|
||
I, too, can confirm that this isn't fixed. BuildID: 20180120113504 I ran MOZ_USE_XINPUT2=1 MOZ_GTK_TITLEBAR_DECORATION="client" ./mach run then tested by: - opening a scrollable webpage - changing focus to another open window - changing focus back to the built firefox window - scrolling two "clicks" downwards I observed that the first scroll "click" had no effect, but the second and onwards did.
Assignee | ||
Comment 41•6 years ago
|
||
Great, thanks for resting, will look at it.
Assignee | ||
Comment 42•6 years ago
|
||
(In reply to Guillaume Destuynder [:kang] (NEEDINFO to ensure replies) from comment #39) > I still lose focus personally with that test: > > ~ $ MOZ_USE_XINPUT2=1 MOZ_GTK_TITLEBAR_DECORATION="client" firefox-nightly > ~ $ sleep 1.5 ; notify-send test > <scroll scroll on webpage> > <notification takes focus and interrupts> > (this works fine without MOZ_USE_XINPUT2) > > BuildID: 20180119103852 (in case its not yet in nightly let me know and ill > retry with tomorrow's build) Which Distro/Gtk+ version do you run? I'm unable to reproduce on Fedora 27 / gtk3-3.22.26.
Assignee | ||
Comment 43•6 years ago
|
||
Looks like gnome folks gave up: https://bugzilla.gnome.org/show_bug.cgi?id=750994#c8 and recommend to use Wayland. I wonder how big complication is it and if benefits from enabled xinput2 outweigh it, especially when the focus bugs should be fixed on recent systems.
(In reply to Martin Stránský [:stransky] from comment #42) > (In reply to Guillaume Destuynder [:kang] (NEEDINFO to ensure replies) from > comment #39) > > I still lose focus personally with that test: > > > > ~ $ MOZ_USE_XINPUT2=1 MOZ_GTK_TITLEBAR_DECORATION="client" firefox-nightly > > ~ $ sleep 1.5 ; notify-send test > > <scroll scroll on webpage> > > <notification takes focus and interrupts> > > (this works fine without MOZ_USE_XINPUT2) > > > > BuildID: 20180119103852 (in case its not yet in nightly let me know and ill > > retry with tomorrow's build) > > Which Distro/Gtk+ version do you run? I'm unable to reproduce on Fedora 27 / > gtk3-3.22.26. I'm using Archlinux with kde plasma/kwin as wm. kwin 5.11.5 gtk3 3.22.26+47+g3a1a7135a2 xorg-server 1.19.6 libinput 1.9.4 xf86-input-libinput 0.26.0
Assignee | ||
Comment 45•6 years ago
|
||
(In reply to Guillaume Destuynder [:kang] (NEEDINFO to ensure replies) from comment #44) > I'm using Archlinux with kde plasma/kwin as wm. > > kwin 5.11.5 > gtk3 3.22.26+47+g3a1a7135a2 > xorg-server 1.19.6 > libinput 1.9.4 > xf86-input-libinput 0.26.0 Hm, tested on: Fedora 27 kwin-5.11.5-1.fc27.x86_64 xorg-x11-server-Xorg-1.19.6-2.fc27.x86_64 gtk3-3.22.26-2.fc27.x86_64 and still no luck to reproduce it with latest nightly.
Comment 46•6 years ago
|
||
I can confirm this is still happening on KDE plasma 5.12 and Firefox 58 on Kubuntu. It's very annoying. Sometimes it will respond to two "clicks" on the wheel and stop scrolling. This is related to windows focus somehow. Steps to reproduce (better with two monitors): 1) open firefox in one display 2) open some other app with scrollable content on the other 3) focus firefox and scroll - works 4) move mouse to the other app without giving focus and scroll - works 5) move mouse back to firefox and scroll - no works!
Comment 47•6 years ago
|
||
FYI, gnome issue 750994 has been migrated to their Gitlab instance: https://gitlab.gnome.org/GNOME/gtk/issues/558
Comment 48•6 years ago
|
||
This bug is reproducible on Firefox 60, KDE Plasma 5.12 on Kubuntu 18.04. If variable Xinput2 enabled touchpad will randomly be extremely slow, until focus is changed, such as by focusing desktop and back to Firefox. Reproducible by doing this: 1. Use click to focus policy 2. Use Firefox windowed with desktop exposed. 3. Click on desktop 4. Scroll Firefox without clicking The scrolling should be much slower. While this can be dirty-fixed with point to focus policy, this behavior also happens randomly with Firefox still on focus.
Comment 49•6 years ago
|
||
I can confirm the behavior from comment 48 in kubuntu 18.04
Comment 50•6 years ago
|
||
Yes this is still an issue Arch Linux Plasma 5.12.90 Firefox Nightly
Comment 52•5 years ago
|
||
This is not an issue right now on Sway when firefox is run in wayland mode.
Comment 53•5 years ago
|
||
(In reply to luis.pabon from comment #52)
This is not an issue right now on Sway when firefox is run in wayland mode.
AFAIK, this bug is only happening with Kwin anyway.
Comment 54•4 years ago
|
||
FWIW KWin developers have discovered in https://bugs.kde.org/show_bug.cgi?id=418304 that it might in fact be a fixable issue in KWin, rather than an unfixable issue in (https://gitlab.gnome.org/GNOME/gtk/issues/558) as originally believed.
If the issue described in this bug report is only affecting people using KWin (i.e. users of KDE Plasma), then it can probably be closed.
Updated•4 years ago
|
Comment 55•4 years ago
|
||
I can confirm this issue and I am also using Kwin.
Comment 56•4 years ago
|
||
https://bugs.kde.org/show_bug.cgi?id=394772 was just fixed upstream, in Plasma 5.19.3. If the only people experiencing this issue are using Plasma with the KWin window manager, we can probably close it as an upstream issue which is now resolved!
Comment 57•4 years ago
|
||
It's probably better to keep this bug report open because other reparenting window managers might be affected by this "bug" too.
Comment 58•3 years ago
|
||
This still happens to me with Plasma/Kwin 5.21.4 - once a notification pops up, Firefox starts only partially responding to scroll events.
Comment 59•2 years ago
|
||
A short summary of actual (bad, often needing patching various libs) workarounds, in descending order of hackiness:
- GDK_CORE_DEVICE_EVENTS=1: disables xinput2 entirely, so you don't get smooth scrolling on the actual touchpads if you have them (if you don't have a touchpad, just do this)
- patch your WM to not grab the scroll wheel buttons - works great if you don't need them, but if you want any scroll wheel bindings that doesn't work
- patch gdk to workaround it
- do extra queries on the enter events as done in https://bugzilla.gnome.org/show_bug.cgi?id=750994 - the patch seems to work fine, but the bug says it breaks something else without saying what (even the revert commit doesn't say anything).
- a hack like chromium's where they try to recognize these events as being completely fake in the first place, and instead just process the button events. https://bugs.chromium.org/p/chromium/issues/detail?id=593453 shows the issues in detecting this consistently, but you could get something that works on your system. (If nothing else, you could set an env variable that specifies devices to fake)
- a timestamp hack like mentioned in https://bugzilla.gnome.org/show_bug.cgi?id=750870 and which I've implemented as https://gist.github.com/talchas/7a3df6c78e10d1cfe47c8b02298a3057 - seems to mostly work, most of the time. It still breaks on the first scroll event after right-click/etc, but at least sometimes works
- There's the xorg patches at https://lists.x.org/archives/xorg-devel/2013-November/039220.html that got rejected for being against the XI2 spec, but hey if the spec is broken...
Comment 60•2 years ago
|
||
The GTK3 patch above seems to work great as a workaround. Certainly an improvement over the stock behaviour. The first scroll event after window focus is missed, but at least subsequent scrolling works correctly, whereas the stock behaviour is completely borked.
Has there been any effort to upstream the workaround patch in GTK3 yet? I'd say a single missed scroll event is very easy to live with, whereas the status quo is unbearable.
Updated•2 years ago
|
Comment 61•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:stransky, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Comment 62•2 years ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Comment 63•1 year ago
|
||
I think I stumbled upon this with Fedora 37 running under Apple Virtualisation Framework (through UTM): https://bugzilla.mozilla.org/show_bug.cgi?id=1825850 . The bug is easily reproduced there by just switching tabs and then trying to scroll. With MOZ_USE_XINPUT2=1, scrolling is disabled until you refocus the Firefox window, with MOZ_USE_XINPUT2=0 everything works fine.
Description
•