1182700 - Wheel scrolling periodically stops working with XInput2

Status: REOPENED

(Core :: Widget: Gtk, defect, P3)

Description

[Botond Ballo [:botond]]

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

[Kan-Ru Chen [:kanru] (UTC+9)]

I tried the GTK3 build today and wheel scrolling does not work at all.

Comment 2

[Kan-Ru Chen [:kanru] (UTC+9)]

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

Comment 3

[Botond Ballo [:botond]]

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

[Andrew Comminos [:acomminos]]

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.

Comment 5

[AnAkkk]

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

[Kan-Ru Chen [:kanru] (UTC+9)]

GDK_CORE_DEVICE_EVENTS=1 works for me

Comment 7

[Cameron McCormack (:heycam)]

[Tracking Requested - why for this release]: Jarring behaviour that we should fix before release.

Comment 8

[AnAkkk]

I can confirm GDK_CORE_DEVICE_EVENTS=1 also fixes the issue for me. Maybe this could be set automatically by firefox?

Comment 9

[Andrew Comminos [:acomminos]]

(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

[Kate Glazko]

Is this a regression? Tracking for 42 because affects usability, we should fix broken wheel scrolling before release.

Comment 11

[AnAkkk]

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.

Comment 12

[Botond Ballo [:botond]]

This is a regression caused by the switch from GTK2 to GTK3. I think it should block the switch.

Comment 13

[Andrew Comminos [:acomminos]]

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.

Comment 14

[Karl Tomlinson (:karlt)]

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

[Karl Tomlinson (:karlt)]

(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

[Kan-Ru Chen [:kanru] (UTC+9)]

(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

[Karl Tomlinson (:karlt)]

(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

[Kestrel]

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

[Andrew Comminos [:acomminos]]

Attachment: Ignore GDK_SCROLL_SMOOTH events with empty deltas.

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

[Andrew Comminos [:acomminos]]

Try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=2b9fa4b8c34a

Comment 22

[Karl Tomlinson (:karlt)]

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

[Andrew Comminos [:acomminos]]

> 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

[Karl Tomlinson (:karlt)]

(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

[Robert Kaiser]

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

Comment 26

[Kate Glazko]

Tracking for Nightly 44 because this has potential user impact, is a regression, and it would be good to get this fixed.

Comment 27

[Kestrel]

I just noticed I can no longer reproduce this bug in 43 or 44.

Comment 28

[Liz Henry (:lizzard) (relman/hg->git project)]

Karl, or Kairo, can you still reproduce this or might it be fixed now?

Comment 29

[Liz Henry (:lizzard) (relman/hg->git project)]

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

[Karl Tomlinson (:karlt)]

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

[Tracy Walker [:tracy]]

works for me on Ubuntu 16.04 with Nightly 51.0a1, 20160823030224

Comment 33

[Karl Tomlinson (:karlt)]

We'll still need to work around this for bug 1207700.

Comment 36

[Stephanie Hobbs]

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)

Comment 37

[Guillaume Destuynder [:kang] [this account is no longer active]]

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)

Comment 38

[Martin Stránský [:stransky] (ni? me)]

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

Comment 39

[Guillaume Destuynder [:kang] [this account is no longer active]]

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

[Stephanie Hobbs]

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.

Comment 41

[Martin Stránský [:stransky] (ni? me)]

Great, thanks for resting, will look at it.

Comment 42

[Martin Stránský [:stransky] (ni? me)]

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

Comment 43

[Martin Stránský [:stransky] (ni? me)]

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.

Comment 44

[Guillaume Destuynder [:kang] [this account is no longer active]]

(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

Comment 45

[Martin Stránský [:stransky] (ni? me)]

(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

[luis.pabon]

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

[Koala Yeung]

FYI, gnome issue 750994 has been migrated to their Gitlab instance:
https://gitlab.gnome.org/GNOME/gtk/issues/558

Comment 48

[firefoxbug]

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

[Brandon Watkins]

I can confirm the behavior from comment 48 in kubuntu 18.04

Comment 50

[mthw0]

Yes this is still an issue

Arch Linux 
Plasma 5.12.90
Firefox Nightly

Comment 52

[luis.pabon]

This is not an issue right now on Sway when firefox is run in wayland mode.

Comment 53

[mthw0]

(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

[Nate Graham]

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.

Comment 55

[christ.derek]

I can confirm this issue and I am also using Kwin.

Comment 56

[Nate Graham]

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

[Vlad Zahorodnii [:zzag]]

It's probably better to keep this bug report open because other reparenting window managers might be affected by this "bug" too.

Comment 58

[Paul Gideon Dann]

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

[talchas]

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

[Paul Gideon Dann]

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.

Comment 61

[BugBot [:suhaib / :marco/ :calixte]]

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

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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

[(GalaxyMaster)]

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.