This also happens when using a regular mouse + touchpad.  Scrolling on the touchpad is the common element.

I've done some local testing and this bug can be fixed by reverting this commit:

https://chromium.googlesource.com/chromium/src/+/62bcee1fab7fde7b93fe299f13f168bb73812b46
commit	62bcee1fab7fde7b93fe299f13f168bb73812b46
author	David Bokan <bokan@google.com>	Wed Apr 27 13:46:53 2016
Fixed first step of scrolling not applying

I'm not very familiar with the internals of X11 events, but please re-examine what this commit is doing, as it breaks touchpad scrolling while using a mouse of any kind on linux.  Thanks!

Thanks for tracking this down Nikil.

I can reproduce this using the trackpoint on my laptop (but not an external mouse). I'ave attached the result of xinput list --long

+Will, could you take a look?

Deleted: xinputlist.txt 5.6 KB

xinputlist.txt 5.6 KB View Download

Sadrul/Dave, I'm OOO the next two weeks, I'll try to get to the bottom of this tonight/tomorrow but even if I succeed, I'll probably need one of you to drive this.

That xinput output looks largely similar to what I have (attached for completeness, I don't experience the issue).

Deleted: xinput-list-long 9.7 KB

xinput-list-long 9.7 KB View Download

If anyone needs help testing a fix let me know.

Will, do you have a trackpoint or an external mouse?  I may have spoken to soon with the external mouse bit, my mouse was actually going through Synergy so it might not be quite the same thing.

I have a synaptics trackpad (Dell Precision M3800 2013) and a Logitech Performance MX that I primarily use.

If someone wants to do some "debugging", one place to look would be https://chromium.googlesource.com/chromium/src/+/6c2262abe85a3b1f03bf849ca670be2e505d34ec/ui/events/devices/x11/device_data_manager_x11.cc#558 - add some printing or something there for the values of |y_offset| and |*valuators|, and see if when the page jumps about if those numbers also do. |*valuators| is cumulative, |y_offset| is the delta between scrolls. If these numbers jump when scrolls do, it's a problem with the xinput2 code, if they don't then it's a problem further up the stack.

The problem occurs even without touching the trackpoint, i.e. the little red dot nestled between G, H, and B key. It seems all I have to do is wait it a bit between scrolling.

I'm experiencing this issue as well. Lenovo Thinkpad t450s. 

Re #12: That's surprising, could you file a separate bug with repro instructions? This bug is occurring because of how we handle device change events.

I've tracked this down. The reason is that the valuator gets reset after a DeviceChangedEvent (with SlaveSwitch reason) but we don't reset the ScrollInfo's position field so we calculate a bogus scroll offset. What I'm unsure of is why this only happens on my trackpoint and not an external mouse; using an external mouse causes a SlaveSwitch but doesn't cause a reset of the valuator as reported from the DeviceEvent.

One way to fix this is to reset the ScrollInfo position on a SlaveSwitch but I'm not sure that's right.

Will, in  issue 593453  you first made it so that we don't call UpdateDeviceList on a DeviceChangedEvent, then you made low-res scrollers (i.e. wheels) use xinput rather than xinput2 so that we don't lose the first wheel tick. Given that the second patch should fix the issue, could we just undo the first change? That fixes this issue and I don't see it as breaking  issue 593453  because wheel devices should now use xinput, right?

True. Shall we revert https://codereview.chromium.org/1883853002 then? Can I do that or does a committer need to do it?

I think that reverting that would also cause scrolling while moving the mouse to cause issues for some people as well - one person had a setup where their scroll wheel appeared as a different device and so the above patch also fixed dodgy scrolling for them too, since SlaveSwitch happened whenever the mouse was moved while scrolling.

But in that case the mouse wheel would be non-precise right? So we'd be using xinput?

Oh yeah. What's the process for reverting that change then?

No worries, I'll do the revert.

Thanks. I'll do some more reading into xinput2 to see if we are doing this invalidation 100% correctly.

I've looked through the GTK3+ source code and found:

https://github.com/GNOME/gtk/blob/master/gdk/x11/gdkdevicemanager-xi2.c#L868

That is the method to handle HierarchyChanged. It basically recomputes the device structure data (Chromium simply wipes it and starts again in this case).

https://github.com/GNOME/gtk/blob/master/gdk/x11/gdkdevicemanager-xi2.c#L952

This is the method for DeviceChanged. If deviceid > 0 then it re-reads the scroll valuators for that device. In this case we should do the same; currently the best way to do that is to call UpdateDeviceList() again.
If sourceid > 0 then it resets the scroll valuator cached value.

I'll try implementing this, see what it does when I unplug mouse, change scroll speed, open new window etc.

 Issue 617834  has been merged into this issue.

Note,  issue 617834  reports the same behavior with middle click which I suspect is just another symptom of this bug. I'm just leaving a note here to make sure we check that case when fixing this as well.

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

Can someone advise as to when this is likely to make it into the wild (and can is be cherry-picked to get it out asap) ?
This has made Chrome unusable for me for about a week now and I'd prefer not to have to continue to use Firefox any more than necessary.

I agree with dbeaumont@google.com.

Firefox aint what it used to be.

 Issue 616308  has been merged into this issue.

I'll request that we merge this into the current beta (52) after we confirm that it doesn't break anything else. You can help by trying out the next Dev-channel push on Linux (the current one doesn't have the above revert). Unfortunately, I don't think we can merge this to the stable release unless it's a security issue or critically affecting a large proportion of the user base and this bug is specific to hardware configurations.

This issue is making Chrome pretty awful to use on Linux laptops as it affects most interactive websites, I recommend merging a fix into stable.

 Issue 618985  has been merged into this issue.

Agreed it's painful, though I don't know where the lines for acceptable merge to stable is so I'll take it up with the TPM. I'd like to see this merged to beta first and at least let it bake there for a bit to make sure we're not accidentally making things even worse.

Here is an easter egg as previously reported in #618985:

Use your left hand on the trackpoint and your right hand on the touchpad. Combo this problem 30 times in a row and the webpage disappears. ^^

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

Confirm,  I also have this issue (see https://bugs.chromium.org/p/chromium/issues/detail?id=617485)

 Issue 617485  has been merged into this issue.

Using the dev build: 53.0.2767.4 dev (64-bit)
I can confirm that the issue no longer occurs (and there are no other obvious issues around trackpad scrolling)

Since this regressed in M51, and we are confident it's fixed in M53, can you merge the revert to M52 to get it to users sooner than later?

Thoughts on backporting to Chrome 51? This is really putting Firefox on all those Lenovo's out there.

https://codereview.chromium.org/2077163003/

I think this CL implements the behaviour I was trying to implement in the reverted CL. This code makes XI_DeviceChanged XIDeviceChange events probe for new scroll data, and makes XI_DeviceChanged XISlaveSwitch events just clear the scroll valuators.

Can we confirm that:
* This doesn't cause the behaviour mentioned in this bug?
* This doesn't stop scrolling from working whilst moving the mouse (this was mentioned in another bug)

Is there a .deb out there I can test?

Re: Merging, unfortunately, reverting broke a use case mentioned in  issue 593453  so we don't want to revert that in stable.

Re #39: Thanks Will, I'm currently OOO traveling but I'll give the patch a go when I get back later this week.

Sorry to anyone affected here. I'm on an affected laptop too so I'm feeling your pain. I'll make sure we have this fixed up by the next stable push at latest.

 Issue 617308  has been merged into this issue.

w.shackleton: I checked http://crrev.com/2077163003 and for me it does not regress this bug or  issue 593453 .

Though, I'm a little confused why it is needed, since this bug is fixed by r399200 and  issue 593453  seems to be fixed by r389117.

Re#43:  issue 593453  only fixes the case for low-res devices; we still want to handle the (more rare) case of having multiple hi-res mice. taviso@ has a particularly bad case of this in  issue 593453  where his mouse registers a separate device for the wheel which means moving the mouse resets the scroll_info classes.

Note: We've disabled xinput2 until we can get the kinks resolved. I'm going to try to merge into 52. See  issue 616308 .

The disable CL has been merged to M52 so we should be back to xinput1 scrolling in the next stable release until we can work the kinks out of xinput2.

 Issue 625162  has been merged into this issue.

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

commit e620fd41c0c6acb7ffb3c44710553797b3c9deb9
Author: w.shackleton <w.shackleton@gmail.com>
Date: Mon Jul 25 21:47:08 2016

Reduced number of UpdateDeviceList calls

I stopped UpdateDeviceList being called every time XISlaveSwitch events occur.

BUG= 609748 

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

[modify] https://crrev.com/e620fd41c0c6acb7ffb3c44710553797b3c9deb9/ui/events/devices/x11/device_data_manager_x11.cc
[modify] https://crrev.com/e620fd41c0c6acb7ffb3c44710553797b3c9deb9/ui/events/devices/x11/device_data_manager_x11.h
[modify] https://crrev.com/e620fd41c0c6acb7ffb3c44710553797b3c9deb9/ui/events/platform/x11/x11_event_source.cc

Issue 621058 has been merged into this issue.