andersk@,Are you still seeing this issue with Latest chrome  i.e.,Latest Dev :38.0.2101.0 or Latest Beta :37.0.2062.20?

Yes. Just tried 38.0.2101.0 on Linux Mint 17.

Firefox fixed this a while ago, comments and code might be interesting: https://bugzilla.mozilla.org/show_bug.cgi?id=958868

Yes, this feature is still missing in 37.0.2062.20 (Official Build 283104) beta and 38.0.2101.0 (Official Build 284576) dev.

Does this still need fixing? I'd be interested at having a stab at fixing it.

Yep, scrolling is still choppy for me in Chromium 39 when scrolling with a trackpad.

Got it working - I'll send a CL for review.

That's amazing. I look forward to trying it out.  :)

https://codereview.chromium.org/688253002

Currently there are a few bugs and no tests but they will come shortly.

Anything new on this? It would greatly enhance user experience on linux to have this kind of smooth scrolling.

I'm quite close to getting a patch set committed to fix this: https://codereview.chromium.org/688253002/
Just waiting for a final review / compatibility check with ChromeOS etc.

Changing the status to Untriaged as this issue is being worked further and fix is already being reviewed.

w.shackleton@ Kindly let us know the latest status of this issue.

Seems to be stuck in code review :/

Anything someone interested but not familiar with the codebase (such as myself) can do to help it along?

I'll chase up the reviewers and try to get this approved.

Is this still stuck in review?

I emailed the reviewers a month ago but still no reply :(

I'll find some more people to add as reviewers to this

How many reviewers are needed for the patch to be merged?

Firefox Linux nightlies are built with Gtk+ 3 as of July 24, with working pixel scrolling.  This should make its way into the Firefox 42 release in November.

 Issue 429521  has been merged into this issue.

 Issue 519588  has been merged into this issue.

Looks like this is being actively worked on.  Assigning to the reviewer for now.

 Issue 163852  has been merged into this issue.

I’m trying out this patch in an Ubuntu PPA package and sometimes upon starting scrolling with the right edge of an ALPS touchpad on my Thinkpad the viewport jumps up considerably (often to the top of the page) and then starts scrolling smoothly (from the wrong position further up the page).

Could this be related to the patch?

Here’s a GIF recording.

Deleted: record.gif 7.6 MB

	record.gif 7.6 MB View Download

I just tested the latest patch (which did not apply cleanly on the latest stable source, but was easy to fix), and the only problem I can find with it is that scrolling to switch tabs is also been affected.

Tiny movements of my high resolution scroll wheel and my fingers on my trackpad cause Chromium to switch tabs when scrolling over the tab bar. The movement threshold required to switch tabs should be increased when using high resolution scrolling input.

The solution to this is to disable this feature on Linux, as it is on Windows and Mac (or possibly re-scale the tab scrolling). Should I include this patch too?

Please disable the tab scrolling "feature".

No, not being able to scroll tabs would be a major annoyance and UX slowdown and inconsistent with many other applications on Linux.

I use tab scrolling all the time, and would be very unhappy if it was removed. It seems like it shouldn't be that hard to just fix the bug. I tried to look into it, but I don't know much about how Chromium works.

Looking into it.

As a follow-up to my comment #23 above. I refreshed the patch to the latest version 7 on the review. On some pages (not all; but here yes, for example) when I click the page and then scroll, there is a jump in scroll position. I think it is resetting to an old scroll location.

Does nobody else see this?

Hmm I can't repro. To test a hypothesis, on line 144 or so of
x11_event_source.cc can you remove the xevent->xcrossing.mode ==
NotifyNormal condition from the if statement? (leaving just the other two
conds and the or) and see what happens?

(I'm on mobile so can't do a diff)

Hmm that won't do it actually.

So, nothing for me to try right now?

I don't think so - can you give steps to repro and devices used?

On this page (https://code.google.com/p/chromium/issues/detail?id=384970), click anywhere, commence scrolling with vertical edge scrolling on ALPS touchpad on Thinkpad X301. The page will jump to an initial scroll location and scroll smoothly from there. With no further clicks, it will smooth scroll correctly. After another click anywhere, it will jump again to the original jump position. So, it will reset to the same location every time.

My touchpad has the following additional snippet in xorg.conf.d:

Section "InputClass"
  Identifier "Pad options"
  Driver "synaptics"
  MatchIsTouchpad "on"
  MatchDevicePath "/dev/input/event*"
  MatchIsTouchpad "on"
  Option "SHMConfig" "1"
  Option "LeftEdge" "0"
  Option "RightEdge" "900"
  Option "TopEdge" "0"
  Option "BottomEdge" "640"
  Option "FingerLow" "7"
  Option "FingerHigh" "8"
  Option "MaxTapTime" "180"
  Option "MaxTapMove" "110"
  Option "VertScrollDelta" "8"
  Option "HorizScrollDelta" "8"
  # Option "CoastingSpeed" "12"
  # Option "CoastingFriction" "30"
  # Option "MinSpeed" "0.25"
  # Option "MaxSpeed" "0.50"
  # Option "AccelFactor" "0.015"
  # Option "EmulateTwoFingerMinZ" "127"
  # Option "EmulateTwoFingerMinW" "15"
  # Option "EmulateWheel" "0"
  # #Option "MaxTapMove" "2"
  # #Option "MaxTapTime" "50"
  # Option "VertTwoFingerScroll" "0"
  # Option "HorizTwoFingerScroll" "0"
  # #Option "FingerPress" "126"
  # Option "FastTaps" "1"
  # #Option "CornerCoasting" "0"
  Option "TrackstickSpeed" "0"
  Option "RTCornerButton" "0"
  Option "RBCornerButton" "3"
  Option "LTCornerButton" "0"
  Option "LBCornerButton" "0"
  #Option "TapButton1" "integer"
  # Option "PressureMotionMinFactor" "1"
  # Option "PressureMotionMaxFactor" "1"
EndSection

Some output from xinput

$ xinput get-feedbacks "AlpsPS/2 ALPS DualPoint TouchPad"
1 feedback class
PtrFeedbackClass id=0
	accelNum is 5
	accelDenom is 1
	threshold is 5

$ xinput list "AlpsPS/2 ALPS DualPoint TouchPad"
AlpsPS/2 ALPS DualPoint TouchPad        	id=11	[slave  pointer  (2)]
	Reporting 7 classes:
		Class originated from: 11. Type: XIButtonClass
		Buttons supported: 12
		Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" None None None None None
		Button state:
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 0:
		  Label: Rel X
		  Range: 0.000000 - 1023.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 1:
		  Label: Rel Y
		  Range: 0.000000 - 767.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 2:
		  Label: Rel Horiz Scroll
		  Range: 0.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIValuatorClass
		Detail for Valuator 3:
		  Label: Rel Vert Scroll
		  Range: 0.000000 - -1.000000
		  Resolution: 0 units/m
		  Mode: relative
		Class originated from: 11. Type: XIScrollClass
		Scroll info for Valuator 2
		  type: 2 (horizontal)
		  increment: 8.000000
		  flags: 0x0
		Class originated from: 11. Type: XIScrollClass
		Scroll info for Valuator 3
		  type: 1 (vertical)
		  increment: 8.000000
		  flags: 0x0


Is that informative?

Excellent, very useful. I'll try to reproduce this.

I couldn't reproduce but I've changed a few things to match more closely the behaviour of GTK3. Please can you try the latest patch set?

Do you have any macro / other mouse software running? It's quite hard to figure out what might be causing this.

I’ve applied the latest patch set #9 and built chromium. Still the same issue. I don’t have any other stuff running besides that xorg.conf.d snippet.

Here’s a (choppy) Screencast

Deleted: Screencast from 10-27-2015 12:31:53 PM.webm 3.5 MB

Screencast from 10-27-2015 12:31:53 PM.webm 3.5 MB Download

Here’s the version I’ve built: 

https://launchpad.net/~towolf/+archive/ubuntu/ppa/+packages

I built the package. Some thoughts.

Ctrl+wheel to zoom is now unsuitably fast. This needs to slow down.

Sometimes scrolling upwards instantly jumps me to the top of the screen. This happens more often (every few seconds) when scrolling up and down repeatedly (taking my hand off the touchpad before changing directions).

Otherwise, pretty good. 

Ctrl+wheel zoom fixed

Scrolling jumping to top of screen also fixed.

Hi.

Patch Set 11 sounded like it may have the issue I reported above. It seems it doesn’t, unfortunately. 

I tried to film my LCD this time to maybe make it more clear what is happening. When I clicked before a smooth edge scroll, I tried to mash the button loudly. Observe the scrollbar position.

Video recording of bug here: https://youtu.be/VOk3BYQhTFc

about:version 48.0.2560.0 (Developer Build) Ubuntu 15.10 (64-bit)
with Patch Set 11

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

commit 49bcd394cf41b1c330c3ffbcae42ff5161352380
Author: w.shackleton <w.shackleton@gmail.com>
Date: Wed Jan 06 17:38:22 2016

Made page zoom handling work with smooth scroll devices
This CL is a smaller set of the CL https://codereview.chromium.org/688253002/
It fixes some broken functionality exposed by that CL.

R=avi
BUG= 384970 

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

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

[modify] http://crrev.com/49bcd394cf41b1c330c3ffbcae42ff5161352380/AUTHORS
[modify] http://crrev.com/49bcd394cf41b1c330c3ffbcae42ff5161352380/content/browser/web_contents/web_contents_impl.cc
[modify] http://crrev.com/49bcd394cf41b1c330c3ffbcae42ff5161352380/content/browser/web_contents/web_contents_impl.h

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

commit c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48
Author: w.shackleton <w.shackleton@gmail.com>
Date: Mon Jan 11 20:08:58 2016

Implemented smooth scrolling using xinput2 in X11.

Adds support for Xinput 2.1 smooth scrolling for hardware that supports it
(such as touchpads and some mice). This provides similar behaviour to that seen
on Mac OS X.

BUG= 384970 

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

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

[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/chrome/browser/ui/views/frame/browser_root_view.cc
[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/chrome/browser/ui/views/frame/browser_root_view.h
[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/base/x/x11_util.cc
[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/devices/x11/device_data_manager_x11.cc
[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/devices/x11/device_data_manager_x11.h
[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/devices/x11/touch_factory_x11.cc
[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/platform/x11/x11_event_source.cc
[modify] http://crrev.com/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48/ui/events/x/events_x.cc

Code is committed, I think this can be closed :)

Thanks for the update, marking as 'Fixed'.

xinput2 support has been disabled in M52 due to  issue 616308  and others. I'm reopening this bug to track turning it back on.

Can you please create a flag to reenable xinput2 support? I never had any problems with it, and now that it's disabled my scrolling is choppy and imprecise. (Fedora 24, Chrome Version 52.0.2743.82, Macbook Pro Retina Mid 2012)

It's on its way (I'm on holiday currently but next week).
https://codereview.chromium.org/2153683002/

 Issue 630489  has been merged into this issue.

 Issue 640501  has been merged into this issue.

The patch in comment #50 seems to have been merged on July 26. When is it going to be available in the stable release? I hope this can be fast tracked, since it was already reviewed and merged in the past, now it just has an additional "if" condition, if I understand correctly.

It’s in M54, branched at position 414607, currently in beta, and scheduled for stable release the week of 2016-10-18 (https://www.chromium.org/developers/calendar).

I was actually asking because I installed the "google-chrome-unstable" Arch Linux package, which is version 55.0.2859.0 dev, but it still has choppy scrolling :/

It works for me in 54.0.2840.27 and 55.0.2859.0 on Ubuntu 16.10, so unless someone else here has an idea, you may want to file a new bug for that.

I just realized I was using Wayland and not X. Is this fix going to land on Wayland as well?

The code I wrote was X only - additional code is required for wayland. When
I start using wayland I might get round to this :p

GNOME 3.22 just switched to Wayland as the default backend (you now have to explicitly choose X at login if you don't want Wayland).

It would be awesome if high resolution scrolling could be implemented for Wayland as well :D

This seems to work on M54 now.

Maybe open another bug for libinput support? This would cover wayland and newer X as well.

Probably also need another bug for libinput kinetic scrolling. Chrome needs to implement this itself: https://wayland.freedesktop.org/libinput/doc/latest/faq.html#faq_kinetic_scrolling

OK I opened this: https://bugs.chromium.org/p/chromium/issues/detail?id=670992

Is another report really needed for the libinput kinetic scrolling?

william you wrote you use wayland, i suppose this is with gnome? how did you start chromium so it does use wayland, not X in wayland?

Yes this is with Arch Linux + GNOME + chromium (no customization of any
sort). Arch Linux uses the latest GNOME version which uses Wayland by
default. I didn't do anything to make chromium use Wayland apart from
starting GNOME.

Il mer 28 dic 2016, 13:40 rupert.t… via monorail <
monorail+v2.2398624333@chromium.org> ha scritto:

By default, Chromium isn't built with Wayland support on Linux.

This means you are likely using X11-based Chromium via XWayland.

I'm guessing this means there is a limitation of XWayland that keeps the XInput 2.1 events from working properly, though it could be a bug in Chromium.

I don't have my Fedora machine nearby with Wayland on it, so I can't debug this right now, but you could try to see if other X programs work properly or not with smooth scrolling on XWayland. Maybe xev ?

I can reproduce the issue when running KDE Plasma 5 o wayland. I don't get high-precision touchpad scrolling when Chrome runs in Xwayland

So the libinput stuff I mentioned is misleading. I don't think Chromium needs to use it. libinput is for the wayland compositor or X server to use.

Next, I did some investigations. Xwayland does provide all the smooth scrolling info to clients, but provides only a single virtual pointer, with scroll increment = 1.0.

Chromium specifically ignores devices with increment = 1.0.

Probably Xwayland should change this? If there is a good reason not to, then maybe Chromium needs a patch. I'll try to look at Xwayland.

 Issue 657104  has been merged into this issue.

It looks like Xwayland correctly sets the increment to 1.0. When I change it to 15.0 (which is the value I get under X directly), scrolling is very slow and does not match native X behavior.

Probably Chromium needs to fix this to not filter out scroll increment 1.0 anymore.

The valuators under Xwayland seem to change at 1/10 the value than under X. When I middle-click scroll with the trackpoint, under X the valuators change in steps of 1.0. Under Xwayland, they change in steps of 0.1.

So increment 1.0 is correct for Xwayland, and isn't a valid way of deciding to ignore XInput2 events as in ui/events/devices/x11/device_data_manager_x11.cc.

b794998819088f76b4cf44c8db6940240c563cf4 needs to be reverted, see  issue 593453  and https://bugzilla.gnome.org/show_bug.cgi?id=750994.

Ping?

The revert in #70 is still needed since this heuristic is broken on all but a particular X configuration, disabling smooth smooth scrolling unnecessarily.

Ping?

It has been saying "Started" for quite some time now... :/

Hey all, this bug is really tracking the original work. I think the context and history is distracting rather than helpful so I'm going to close this one. 

agoode@, should we open a new bug or is this really about  issue 593453  and we can use that?

I think  issue 593453  probably covers it, since the issues on various systems all come from the heuristics that try to fix the missing scroll tick.

For anyone who stumbles across this looking for libinput kinetic scrolling support, see https://bugs.chromium.org/p/chromium/issues/detail?id=763791