Wheel scrolling periodically stops working with XInput2

REOPENED
Assigned to

Status

()

defect
P3
normal
REOPENED
4 years ago
11 days ago

People

(Reporter: botond, Assigned: stransky)

Tracking

(Blocks 1 bug)

Trunk
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42+ disabled, firefox43+ disabled, firefox44+ disabled)

Details

(Whiteboard: tpi:+)

Attachments

(1 attachment)

Reporter

Description

4 years ago
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).
I tried the GTK3 build today and wheel scrolling does not work at all.
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

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

4 years ago
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
GDK_CORE_DEVICE_EVENTS=1 works for me
[Tracking Requested - why for this release]: Jarring behaviour that we should fix before release.

Comment 8

4 years ago
I can confirm GDK_CORE_DEVICE_EVENTS=1 also fixes the issue for me. Maybe this could be set automatically by firefox?
(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

4 years ago
Is this a regression? Tracking for 42 because affects usability, we should fix broken wheel scrolling before release.
Flags: needinfo?(botond)

Comment 11

4 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

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

Updated

4 years ago
Flags: needinfo?(botond)
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.
Flags: needinfo?(karlt)

Updated

4 years ago
Keywords: regression
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.
Flags: needinfo?(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?
Flags: needinfo?(kchen)
(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.
Flags: needinfo?(kchen)
(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

4 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.
Duplicate of this bug: 1198741
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!
Attachment #8655306 - Flags: review?(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?
Flags: needinfo?(andrew)
Attachment #8655306 - Flags: review?(karlt)
> 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.
Flags: needinfo?(andrew)
(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.
No longer blocks: ship-gtk3

Comment 25

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

Comment 26

4 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

4 years ago
I just noticed I can no longer reproduce this bug in 43 or 44.
Karl, or Kairo, can you still reproduce this or might it be fixed now?
Flags: needinfo?(karlt)
Flags: needinfo?(kairo)
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!
Flags: needinfo?(karlt)
Flags: needinfo?(kairo)
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.

Updated

4 years ago
Duplicate of this bug: 1194067
works for me on Ubuntu 16.04 with Nightly 51.0a1, 20160823030224
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
We'll still need to work around this for bug 1207700.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: Wheel scrolling periodically stops working with GTK3 → Wheel scrolling periodically stops working with XInput2

Updated

3 years ago
Priority: -- → P3
Whiteboard: tpi:+
Duplicate of this bug: 1359226
Duplicate of this bug: 1404561

Comment 36

2 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)
(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.
Flags: needinfo?(chris)
Assignee

Updated

Last year
Flags: needinfo?(gdestuynder)
Assignee

Updated

Last year
Assignee: nobody → stransky
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)
Flags: needinfo?(gdestuynder)

Comment 40

Last year
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.
Flags: needinfo?(chris)
Great, thanks for resting, will look at it.
(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.
Flags: needinfo?(gdestuynder)
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
Flags: needinfo?(gdestuynder)
(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

Last year
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

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

Comment 48

Last year
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.
I can confirm the behavior from comment 48 in kubuntu 18.04

Comment 50

Last year
Yes this is still an issue

Arch Linux 
Plasma 5.12.90
Firefox Nightly
You need to log in before you can comment on or make changes to this bug.