The multiple profiles is a red herring -- this happens with two windows from a single Chrome profile.  (I was using multiple profiles to compare the smooth-scrolling and non-smooth-scrolling behaviors.)

Very interesting.

The relevant trigger seems to be the mouse pointer leaving and re-entering the window.  Whenever this happens, even with just one window, the next wheel tick gets ignored.

Repros with and without smooth scrolling.  Does not repro on Windows.

Could this be another xinput2 bug? Perhaps the focus isn't set on the window until after the XIScrollEvent is processed?

It looks like ui::EventHandler gets the MouseWheelEvent but it never makes it to RenderWidgetHostViewAura::ProcessMouseWheelEvent for some reason.

Did a bisect down to https://chromium.googlesource.com/chromium/src/+log/be264faf0286a508b23e181d3cb25723f2eff2bf..c8b8e4d0d48dd06757354a5ee61efa9aa45de434 which contains the touchpad smooth scroll patch. so it seems likely.

Will, could you please take a look?

This behaviour is also seen in GTK3+ apps such as evince, gnome-terminal. It's because xinput2 scroll events use absolute positioning that changes when another window is focused (hence the first event is to work out where this absolute position is). I think the underlying problem is that the evdev driver only outputs one event when a new window is focused.

This can be fixed however. There is some code that enumerates all xinput2 scroll devices and for each it finds, disables xinput1 and enables xinput2 event reading. For devices that are classic scroll wheels (which are those with `increment` of -1 or 1) we can not enable xinput2 and stick with xinput1 input. Any device outputting more precise scroll values will either output these double events at the beginning or will be too high resolution to be noticed.

I'll submit a CL tomorrow (should be a couple of lines).

https://codereview.chromium.org/1792623003 fixes this.

This almost seems like the problem I've just started having on my Fedora workstation after a stable update. The first tick of my scroll wheel is discarded, but that also happens after *moving* my pointer. If I keep my pointer perfectly still, the first tick is discarded but then it works normally.

If I move my pointer, this repeats - first tick discarded, then normal.

The problem is keeping my pointer perfectly still while I scroll is frustratingly difficult.

It looks like the cause of my problem is that xinput2 splits my single physical mouse into two virtual pointers, id=10 is responsible for movement and id=9 is the scroll wheel.

It seems like getting a scroll event is interpreted as switching virtual devices, and then this bug occurs. I think fixing this bug will make my problem go away. I think I'm hit by this worse than others on this bug, very annoying!

Interesting---there's a bit of code that invalidates the scroll data under certain conditions. Since this is fairly easy to reproduce with two mice I can try and make it not invalidate under most recent mouse switch.

Do you think we should revert xi2 support until we figure out the edge cases here? It looks like this is going to take a while, and chrome stable is unusable for me.

Will, WDYT? Would you be able to have a fix soon? (In the next week or two we could still merge into M51)

I've been away from my desktop, but I can clone chrome to my laptop and get this done sooner (desktop would be Saturday). It shouldn't be too hard (as all problems initially appear...) 

Issue https://codereview.chromium.org/1883853002/ fixes this - I've tested this with two mice and the described behaviour is no longer happening. I can't test with the specific hardware but reading X docs this seems like it should fix.

Thanks! Just FYI: on codereview.chromium.org, you have to "Publish+Mail Comments" before reviewers will see it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/47c6f3e7252ece9b52e5b86d40944e66442ea7aa

commit 47c6f3e7252ece9b52e5b86d40944e66442ea7aa
Author: w.shackleton <w.shackleton@gmail.com>
Date: Tue Apr 19 11:13:59 2016

Fixed first step of scrolling not applying

I fixed the first step of scrolling not applying when switching from one slave
mouse device to another. This bug was happening because the Xinput2 event
XIDeviceChangedEvent is used for two different reasons, a device's properties
changing and the current slave device being switched. This code checks that the
reason field is set to XIDeviceChange (rather than XISlaveSwitch).

BUG= 593453 

Review URL: https://codereview.chromium.org/1883853002

Cr-Commit-Position: refs/heads/master@{#388182}

[modify] https://crrev.com/47c6f3e7252ece9b52e5b86d40944e66442ea7aa/ui/events/platform/x11/x11_event_source.cc

I think we'd like to merge this to M51, right? Lets let this hit Dev channel and wait for confirmation it fixes the issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b794998819088f76b4cf44c8db6940240c563cf4

commit b794998819088f76b4cf44c8db6940240c563cf4
Author: w.shackleton <w.shackleton@gmail.com>
Date: Fri Apr 22 15:44:50 2016

Changed DeviceDataManagerX11 to use xinput1 for low resolution scroll devices

I added functionality to DeviceDataManagerX11 that uses xinput1 for
devices that gain no extra precision from using xinput2. This means that
for devices that don't ouput two scroll events on focus of a window
(which seems to be the case for classic mice driven by evdev) we don't
experience a missed scroll event on focus.

BUG= 593453 

Review URL: https://codereview.chromium.org/1792623003

Cr-Commit-Position: refs/heads/master@{#389117}

[modify] https://crrev.com/b794998819088f76b4cf44c8db6940240c563cf4/ui/events/devices/x11/device_data_manager_x11.cc

Requesting merge to 51 for the above two patches as they seem to fix numerous complaints about mouse wheels on Linux. See also  issue 603998 

 Issue 603998  has been merged into this issue.

Your change meets the bar and is auto-approved for M51 (branch: 2704)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/62bcee1fab7fde7b93fe299f13f168bb73812b46

commit 62bcee1fab7fde7b93fe299f13f168bb73812b46
Author: David Bokan <bokan@google.com>
Date: Wed Apr 27 13:46:53 2016

Fixed first step of scrolling not applying

I fixed the first step of scrolling not applying when switching from one slave
mouse device to another. This bug was happening because the Xinput2 event
XIDeviceChangedEvent is used for two different reasons, a device's properties
changing and the current slave device being switched. This code checks that the
reason field is set to XIDeviceChange (rather than XISlaveSwitch).

BUG= 593453 

Review URL: https://codereview.chromium.org/1883853002

Cr-Commit-Position: refs/heads/master@{#388182}
(cherry picked from commit 47c6f3e7252ece9b52e5b86d40944e66442ea7aa)

Review URL: https://codereview.chromium.org/1923323002 .

Cr-Commit-Position: refs/branch-heads/2704@{#264}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/62bcee1fab7fde7b93fe299f13f168bb73812b46/ui/events/platform/x11/x11_event_source.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/155a331d0bc3fba7d1f955e8612c68c9a99eec72

commit 155a331d0bc3fba7d1f955e8612c68c9a99eec72
Author: David Bokan <bokan@google.com>
Date: Wed Apr 27 15:59:14 2016

Changed DeviceDataManagerX11 to use xinput1 for low resolution scroll devices

I added functionality to DeviceDataManagerX11 that uses xinput1 for
devices that gain no extra precision from using xinput2. This means that
for devices that don't ouput two scroll events on focus of a window
(which seems to be the case for classic mice driven by evdev) we don't
experience a missed scroll event on focus.

BUG= 593453 

Review URL: https://codereview.chromium.org/1792623003

Cr-Commit-Position: refs/heads/master@{#389117}
(cherry picked from commit b794998819088f76b4cf44c8db6940240c563cf4)

Review URL: https://codereview.chromium.org/1925713002 .

Cr-Commit-Position: refs/branch-heads/2704@{#265}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/155a331d0bc3fba7d1f955e8612c68c9a99eec72/ui/events/devices/x11/device_data_manager_x11.cc

I've merged both the fixes into the M51 branch, they should show up in the next beta push. They're in the current Dev channel release. I'll mark this as closed. Feel free to reopen if you're still experiencing this or file a new bug.

Still seeing this bug on 51.0.2704.47 beta (64-bit).  I'm on an up-to-date Arch Linux using KDE Plasma and xf86-input-libinput.  Tested with multiple mice and they all exhibit this problem.

To clarify, scrolling after moving the pointer within the Chrome window was never an issue for me.  The first tick would be lost only after moving my cursor outside the window.  Focus on click/focus follows mouse doesn't make a difference, either.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ec3cd7e9c00b5fea3c175a404014eb32e072ec7

commit 9ec3cd7e9c00b5fea3c175a404014eb32e072ec7
Author: bokan <bokan@chromium.org>
Date: Fri Jun 10 16:12:31 2016

Revert "Fixed first step of scrolling not applying"

This reverts commit 47c6f3e7252ece9b52e5b86d40944e66442ea7aa. This was causing
an issue where touchpad scrolling, moving the mouse via a trackpointer, and
touchpad scrolling again caused a scroll jump because the SlaveSwitch resets
the scroll valuator but we stopped resetting the ScrollInfo's position field
with this CL.

This CL was originally meant to address  issue 593453 , where a first tick of a
scroll wouldn't apply because the SlaveSwitch cleared out the ScrollInfo fields
but that should be addressed by Will's second CL in that issue:
https://codereview.chromium.org/1792623003 which disables xinput2 for
non-precise devices.

BUG= 609748 , 593453 

Review-Url: https://codereview.chromium.org/2055913002
Cr-Commit-Position: refs/heads/master@{#399200}

[modify] https://crrev.com/9ec3cd7e9c00b5fea3c175a404014eb32e072ec7/ui/events/platform/x11/x11_event_source.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9ec3cd7e9c00b5fea3c175a404014eb32e072ec7

commit 9ec3cd7e9c00b5fea3c175a404014eb32e072ec7
Author: bokan <bokan@chromium.org>
Date: Fri Jun 10 16:12:31 2016

Revert "Fixed first step of scrolling not applying"

This reverts commit 47c6f3e7252ece9b52e5b86d40944e66442ea7aa. This was causing
an issue where touchpad scrolling, moving the mouse via a trackpointer, and
touchpad scrolling again caused a scroll jump because the SlaveSwitch resets
the scroll valuator but we stopped resetting the ScrollInfo's position field
with this CL.

This CL was originally meant to address  issue 593453 , where a first tick of a
scroll wouldn't apply because the SlaveSwitch cleared out the ScrollInfo fields
but that should be addressed by Will's second CL in that issue:
https://codereview.chromium.org/1792623003 which disables xinput2 for
non-precise devices.

BUG= 609748 , 593453 

Review-Url: https://codereview.chromium.org/2055913002
Cr-Commit-Position: refs/heads/master@{#399200}

[modify] https://crrev.com/9ec3cd7e9c00b5fea3c175a404014eb32e072ec7/ui/events/platform/x11/x11_event_source.cc

taviso@, could you please try the latest Linux dev channel and see if this is still fixed?

I backed out the original CL since it was causing  issue 609748  but I think your case should remain fixed due to Will's second patch: 

commit b794998819088f76b4cf44c8db6940240c563cf4
Changed DeviceDataManagerX11 to use xinput1 for low resolution scroll devices

Darn, it's broken again on 53.0.2767.4.

Stable is working great.

Drats. Ok, thanks, I'll make sure we fix this before 53 ships.

taviso@: do you have a chromium build where you could try out https://codereview.chromium.org/2077163003/ and see if it helps? If not we can land it and try in dev-channel.

taviso@: does your scroll wheel work in eg. an xinput2 version of Evince (ie. a GTK3+ application)?

Hey, I don't have a build but if you can get me one I can test it.

Will: Not by default, but if I disable resetting scroll valuators it works.

This doesn't work on my system. With the libinput driver (the replacement for evdev) on X, all my devices have an increment of 15, including mouse wheels. On Xwayland, all devices have an increment of 1.

Consequently, this workaround doesn't work on X (I still lose the first mouse wheel motion) and breaks Xwayland (no devices trigger smooth scrolling).

Note that this bug is not a Chromium bug: Gtk has this same problem under X, and they haven't been able to fix it:
https://bugzilla.gnome.org/show_bug.cgi?id=750994

I suggest reverting this change, since it has no effect on systems using libinput and breaks precise scrolling on Xwayland.

(Wayland fixes this by using relative events for scrolling.)

This is probably going to be a Won't Fix if  issue 384970  (hi-res scrolling on X) is to be supported.

Unfortunately, I don't understand the Linux event landscape well enough to make any judgments here.

+sadrul@, do you have a feeling on how we can best support all these configurations? Or which we should prioritize?

So we might be able to make some progress upstream and get an xinput property set on devices with discrete steps (mousewheels) so we can detect them without a heuristic. The current heuristic seems to work on the deprecated evdev X input driver but that isn't guaranteed. This would also allow other toolkits to implement a workaround.

evdev driver (deprecated): https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/

libinput driver (new): https://cgit.freedesktop.org/xorg/driver/xf86-input-libinput/


On Xwayland, we don't have access to individual devices. It looks like this:

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:13                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:13            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:13                    	id=8	[slave  keyboard (3)]

If we figure out a way for pointers to declare their need for the XINPUT2 workaround, we could probably add a new xwayland pointer through which only the mousewheel events go and which has the property.

Couldn't we get a flag or an environment variable or something in the meantime so the user can force enable this?

This really harms chrome's usubility in a wayland session, I've switched to firefox in the meantime where I can just force enable high resolution scrolling with an environment variable

This requires attention from someone who understands the various Linux environments. I do not nor have the time to dedicate here.

What is the visible issue with high-precision trackpads on Wayland? Does it revert to low-precision scrolling or missing the first tick? Given that this has been the behavior for over a year and does work in certain configurations, I'm going to close this bug. Please file a separate bug describing the behavior and environment configuration and we can look into fixing it from there.

Specifically on Wayland, I do wonder how this works for ChromeOS as various boards use Wayland there.

@bokan

It reverts to low resolution scrolling (scrolling in steps, a very noticeably worse experience).

Was originally discussed in this bug, and looks like it got closed in favor of this one: https://bugs.chromium.org/p/chromium/issues/detail?id=384970#c72

Files separate bug here: https://bugs.chromium.org/p/chromium/issues/detail?id=712737

Thank you. Yah, both bugs have been accumulating various issues though. I think starting fresh will help keep things clear. Thank you for filing the new one!