New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 32 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2016
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Regression

Sign in to add a comment

Issue 582547: Starting with Chrome 49.0.2623.28 beta (64-bit), mouse/trackpad scrolling is reversed

Reported by, Jan 29 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.28 Safari/537.36

Steps to reproduce the problem:
0. (Using ubuntu, xmonad, and .Xmodmap to reverse pointer values 4,5 and 6,7)
1. Google search anything
2. Use two-finger scrolling or mouse wheel scrolling

What is the expected behavior?
I expected the previous behavior (chrome 48) where scrolling matches by system setup, which is 'natural' scrolling.

What went wrong?
The rest of the system scrolls 'naturally' (content moves in the scroll direction, opposite the motion of the scrollbars) including terminals, menus, other browsers, editors.  But chrome 49 scrolls backwards from the rest of the system.

Did this work before? Yes Chrome 48

Chrome version: 49.0.2623.28  Channel: beta
OS Version: Ubuntu trusty 14.04.3
Flash Version: 

It definitely seems like chrome is reversing the scroll inputs from the trackpad and mouse wheel.

If this is an expected feature, a flag to enable/disable reversed scrolling would be ok for folks that have a setup and contradicts.

Comment 1 by, Jan 29 2016

Labels: -Cr-UI Cr-IO-Mouse

Comment 2 by, Feb 1 2016

I am also seeing this problem. I have ubuntu configured for "natural" scrolling via xmodmap -e "pointer = 1 2 3 5 4", and it works fine in Firefox but not in Chrome 49.0.2623.28.

Comment 3 by, Feb 1 2016

It works fine in Chrome 48.0.2564.97.

Comment 4 by, Feb 3 2016

Labels: Needs-Feedback
scott@ As per the comment #3, Could you please try the issue by upgrading chrome to latest stable 48.0.2564.97 and update the thread if the issue still exists.

Thank you!

Comment 5 by, Feb 3 2016

I have confirmed that the issue does not exist in chrome stable version 48.0.2564.97, that is, in chrome stable it works as expected on my ubuntu system.

Comment 6 by, Feb 3 2016

Some additional information from a different experiment with chrome beta version 49.0.2623.28:

(not to confuse things but it seems that more information may be useful)

I have another ubuntu system, a server, that runs Xvnc configured for an XFCE desktop (not Unity and not Xmonad like I use on my local system natively).  I connect to that XFCE desktop remotely via vncviewer (xvnc4viewer package) and run chrome beta 49.0.2623.28...

As expected scrolling is "natural" for applications since my local system has the mouse scroll directions reversed (via xmodmap as in the previous comments), and those events are shipped to the remote desktop as is.  In this scenario however, chrome beta scrolls like everything else, that is, "natural" like the rest of the system and not reversed as it is on my local system.

Is chrome 49 more "aware" of desktop environment and/or mouse configurations in some cases?

If that hits a nerve and I can try any other cases, I'll be glad to try as time permits.

Comment 7 by, Feb 4 2016

Confirmed that the issue still exists in version [49.0.2623.39 beta (64-bit)]; the scrolling behavior is the same as the previous 49-beta version.

Comment 8 by, Feb 23 2016

 Issue 584411  has been merged into this issue.

Comment 9 by, Feb 23 2016

Labels: -Type-Bug -Needs-Feedback Type-Bug-Regression Needs-Bisect
Status: Untriaged (was: Unconfirmed)
It may be helpful to try some Chromium builds from between 359700 and 369907 to figure out where this broke.

Comment 10 by, Feb 23 2016

I vaguely remember being able to reproduce this bug when looking at  bug 584411 , but I'm on a different computer now and can't reproduce the problem. :\

Comment 11 by, Feb 23 2016

The regression seems to have happened between 368644 and 368651.  Not sure where to find the exact changes between those builds to investigate further.

Comment 12 by, Feb 23 2016

This commit is broken:
This commit should work:

I looked at the commit messages and diffs and nothing stood out for me as an obvious cause.  There was one third-party library that changed versions (skia) but that looks like a graphics library and I didn't find any indication that it provides mouse interaction.

Comment 13 by, Feb 23 2016

Labels: -Needs-Bisect
Oh, probably r368645.

Comment 14 by, Feb 23 2016

The problem here is that Chromium now uses Xinput2 to enable smooth scrolling---this means that Chromium receives linear scroll quantities from the X server, rather than button clicks. The Xmodmap technique for swapping the scroll direction is now deprecated (you'll find that any other Xinput2 app is now also "broken"---try gnome-terminal, evince etc). The Xmodmap command only swaps the Xinput1 button presses.

The way to fix this is to use xinput to swap your scroll direction, as follows:
xinput set-prop <mouse:id_or_name_here> "Evdev Scrolling Distance" -1 1 1
That -1 swaps the direction of vertical scrolling.

Comment 15 by, Feb 23 2016

The previous comment,, appears to be correct.

I've verified that this on my local system (as described in the original report).  It turns out I apparently don't have many apps using xinput2 (or those input events) on ubuntu 14.04.

Given that, I'd argue that this isn't a defect or regression with chrome.

Comment 16 by, Feb 23 2016

Status: WontFix (was: Untriaged)
Thanks for the feedback Will and Scott. Sounds like a WontFix.

Comment 17 by, Feb 23 2016

This makes me very sad.  The solution doesn't actually work for many mouses.  For instance:

$ xinput set-prop 8 "Evdev Scrolling Distance" -1 1 1
property 'Evdev Scrolling Distance' doesn't exist, you need to specify its type and format

Many mouses don't have this property, and so with xinput2 it's impossible to actually change this setting.  I hate to say it, but until Chrome or xinput2 support this correctly, I'll probably be using Firefox :-(

Comment 18 by, Feb 23 2016

Is there an xinput2 project somewhere I can file a bug against?

Comment 19 by, Feb 23 2016

Can you paste the output of `xinput --list-props <devnum>` and `xinput list <devnum>`?

Also can you give the version number of xinput and the version number of your X server? As I understood it X supported this universally now - I can set this property on regular USB mice.

I think this is more a problem with the fact that the method people have been using to obtain natural scrolling has always been a massive hack (swapping the scroll up and scroll down buttons over).

Comment 20 by, Feb 23 2016

I will add that, yes I ran into some pain getting xinput to do what I wanted particularly with the Synaptics touchpads since their supported properties are very different.  I found that some unity tools seem to know what to do to make it work as well with less knowledge of the actual individual device properties.

In either case, it's not a chrome(ium) but per se.  Maybe some release notes or help content with mouse stuff related to the new smooth scrolling support on Linux would help a little.  Not sure.

Comment 21 by, Feb 23 2016

I think you'd be best looking at the xinput driver that you're mouse is using (eg. xserver-xorg-input-evdev in ubuntu). Obviously the evdev input parameter I pasted earlier only applies to evdev driven mice (which should be basically all of them these days iirc). I believe that evdev has superseded lots of older legacy mouse drivers that have not many options.

Comment 22 by, Feb 23 2016

Here's a workaround:

There's currently a three-digit limit on the "step size", but -99 does work, and with some DOM hacking one can change the size to 4 and get larger negative values.  I've sent a PR to support natural scrolling natively.

Comment 23 by, Feb 23 2016

This is in Ubuntu 14.04, so it's pretty old - it's possible newer versions of evdev have this fixed.  Agreed that swapping buttons is crummy.  Here's all the info I've got.

$ xinput list-props 8

Device 'Kingsis Peripherals  Evoluent VerticalMouse 3 ':
        Device Enabled (142):   1
        Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (265):     0
        Device Accel Constant Deceleration (266):       1.000000
        Device Accel Adaptive Deceleration (267):       1.000000
        Device Accel Velocity Scaling (268):    10.000000
        Device Product ID (258):        6780, 104
        Device Node (259):      "/dev/input/event2"
        Evdev Axis Inversion (269):     0, 0
        Evdev Axes Swap (271):  0
        Axis Labels (272):      "Rel X" (152), "Rel Y" (153), "Rel Vert Wheel" (264)
        Button Labels (273):    "Button Left" (145), "Button Middle" (146), "Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149), "Button Horiz Wheel Left" (150), "Button Horiz Wheel Right" (151), "Button Side" (262), "Button Extra" (263), "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261), "Button Unknown" (261)
        Evdev Middle Button Emulation (274):    0
        Evdev Middle Button Timeout (275):      50
        Evdev Third Button Emulation (276):     0
        Evdev Third Button Emulation Timeout (277):     1000
        Evdev Third Button Emulation Button (278):      3
        Evdev Third Button Emulation Threshold (279):   20
        Evdev Wheel Emulation (280):    0
        Evdev Wheel Emulation Axes (281):       0, 0, 4, 5
        Evdev Wheel Emulation Inertia (282):    10
        Evdev Wheel Emulation Timeout (283):    200
        Evdev Wheel Emulation Button (284):     5
        Evdev Drag Lock Buttons (285):  0

$ xinput list 8

Kingsis Peripherals  Evoluent VerticalMouse 3   id=8    [slave  pointer  (2)]
        Reporting 5 classes:
                Class originated from: 8. Type: XIButtonClass
                Buttons supported: 13
                Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down" "Button Horiz Wheel Left" "Button Horiz Wheel Right" "Button Side" "Button Extra" "Button Unknown" "Button Unknown" "Button Unknown" "Button Unknown"
                Button state:
                Class originated from: 8. Type: XIValuatorClass
                Detail for Valuator 0:
                  Label: Rel X
                  Range: -1.000000 - -1.000000
                  Resolution: 1 units/m
                  Mode: relative
                Class originated from: 8. Type: XIValuatorClass
                Detail for Valuator 1:
                  Label: Rel Y
                  Range: -1.000000 - -1.000000
                  Resolution: 1 units/m
                  Mode: relative
                Class originated from: 8. Type: XIValuatorClass
                Detail for Valuator 2:
                  Label: Rel Vert Wheel
                  Range: -1.000000 - -1.000000
                  Resolution: 1 units/m
                  Mode: relative
                Class originated from: 8. Type: XIScrollClass
                Scroll info for Valuator 2
                  type: 1 (vertical)
                  increment: -1.000000
                  flags: 0x2 ( preferred )

$ xinput --version

xinput version 1.6.1
XI version on server: 2.3

$ Xorg -version

X.Org X Server 1.15.1
Release Date: 2014-04-13
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.2.0-76-generic x86_64 Ubuntu
Current Operating System: Linux 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-3.13.0-77-generic root=/dev/mapper/dhcp--172--22--32--235--vg-root ro ima_hash=sha256 elevator=cfq quiet splash
Build Date: 12 February 2015  02:49:29PM
xorg-server 2:1.15.1-0ubuntu2.7 (For technical support please see 
Current version of pixman: 0.30.2
        Before reporting problems, check
        to make sure that you have the latest version.

$ dpkg -s xserver-xorg-input-evdev

Package: xserver-xorg-input-evdev
Status: install ok installed
Priority: optional
Section: x11
Installed-Size: 138
Maintainer: Ubuntu X-SWAT <>
Architecture: amd64
Version: 1:2.8.2-1ubuntu2
Provides: xorg-driver-input
Depends: libc6 (>= 2.14), libmtdev1 (>= 1.1.0), libudev1 (>= 183), xorg-input-abi-20, xserver-xorg-core (>= 2:
Description: X.Org X server -- evdev input driver
 This package provides the driver for input devices using evdev, the Linux
 kernel's event delivery mechanism.  This driver allows for multiple keyboards
 and mice to be treated as separate input devices.
 More information about X.Org can be found at:
 This package is built from the xf86-input-evdev driver module.
Original-Maintainer: Debian X Strike Force <>

Comment 24 by, Mar 2 2016

FYI I fixed this by installing xserver-xorg-lts-wily and removing all the conflicting packages. (Warning: it will try to upgrade your kernel to 4.x. You might want to remove that before install.)

Comment 25 by, Mar 2 2016

(You still need to set the xinput prop, but it will show up after upgrade.)

Comment 26 Deleted

Comment 27 Deleted

Comment 28 by, Mar 3 2016

Sorry to say, but xinput or xmodmap affect all apps, not just Chrome. Fixing Chrome's scroll direction at the expense of other Xwindow apps is not an option. 

Have you even considered that people already *have* natural scrolling? Scrolling direction is an attribute bound to your hardware. The next mouse might have buttons 4 and 5 swapped in hardware, kissing your software-based natural scrolling goodbye.

The right place to configure natural scrolling for your vertical scroll wheel is in the xorg.conf file (Option "ButtonMapping"), like all the other buttons and scroll wheels. This will make sure that all X apps get the same scrolling direction.

Defining natural scrolling for each and every application separately (as you did for Chrome) just breaks the common look and feel of X.

Please repoen this bug report.

Comment 29 by, Mar 3 2016

Chrome does not define its own definition of natural scrolling - it uses
xinput2 and scrolls in the same direction as all other xinput2 apps.
Xinput2 is here to stay and an increasingly large number of applications
will start using it, so the problem is that the method of enabling natural
scrolling by swapping buttons is simply no longer valid.

On Thu, 3 Mar 2016 08:39 via Monorail, <> wrote:

Comment 30 by, Mar 3 2016

You mean xinput2 defines the scroll direction of Chrome?

How comes that the conflict between xinput2 and "traditional" Xwindow apps (xterm, firefox, whatever) wrt scrolling direction couldn't be avoided?

Comment 31 by, Mar 3 2016

any workaround to configure the xinput2? I can not find any documentation yet.


Comment 32 by, Mar 4 2016

Several workarounds listed here: 
"Alternate method" (old evdev) reportedly works as a replacement for using xmodmap and swapping buttons 4 and 5.

Comment 33 by, Mar 10 2016

FWIW, I'm using Ubuntu 14.04 and I enabled natural scrolling through the mouse settings panel and it works just fine. I agree this isn't a bug in Chrome and so WontFix is the correct action here.

Comment 34 by, Mar 10 2016

 Issue 591998  has been merged into this issue.

Comment 35 by, Mar 22 2016

 Issue 594547  has been merged into this issue.

Comment 36 by, Mar 22 2016

 Issue 592807  has been merged into this issue.

Comment 37 by, Apr 4 2016

The best way I have found to fix this system wide was this answer

In case other apps are now non natural scroll enable reverse scrolling in the mouse settings :)

Comment 38 by, Apr 14 2016

Please do the community a favor and keep the default scroll direction *compatible to all the other XWindow applications*. The current version is apita.

Maybe its an option to make it configurable within the settings menu, next to the Appearance flags?

Changing the scroll direction globally is not a solution, because it affects the scroll direction of other apps as well (regardless via xmodmap or xinput2 or some gnome-only settings program).


Comment 39 by, Apr 14 2016


Comment 40 by, Apr 15 2016

Chrome behaves in the same way as every other xinput2 app, such as evince, gnome-terminal, nautilus, or anything using GTK+3. Hence it doesn't make sense to put any configuration options in Chrome - this would be like having such an option in the settings of Evince.

Comment 41 by, Apr 16 2016

What about the users not using gnome, evince or nautilus, but xterm, firefox, thunderbird, claws, xpdf, emacs, and tons of others? 

This is not about which app is right in its scrolling style. Its about having a common style for all. As user I see that chrome broke ranks with version 49. This should be fixed.

From a developers perspective xinput2 is an api to make hardware events (button clicked, scroll wheel moved, touchpad touched, etc.) available to the application. AFAICS xinput2 makes no assumptions about how the application interprets these events. Its up to chrome to decide in which direction to scroll, as with the old xinput.

Comment 42 by, Apr 16 2016

This is not about that either. Chrome is scrolling in the same direction as before, and in the same direction as other applications using xinput2. Swapping buttons 4 and 5 to reverse scrolling is simply deprecated. It no longer applies to modern software.

Comment 43 by, Apr 17 2016

If I dont swap buttons 4 and 5, then chrome 50 still scrolls into another direction than the others. Moving back to version 48 fixes this problem.

Comment 44 by, Apr 17 2016

Hmm - can you attach the output of "xinput list --long"? The direction used
in chrome is definitely the same as in gtk3 so this sounds odd.

Comment 45 by, Apr 18 2016

OK, so now I got confused.

Apparently the "old style" apps are affected by both xmodmap and xinput2. Using xinput to set "Evdev Scrolling Distance" (as recommended above) without using the xmodmap way to swap buttons 4 and 5 enables natural scrolling for all. That was new to me.

My apologies to all. And thanx for your patience.


Comment 46 by, Jul 18 2016

For completeness, this appears to be fixed after upgrading to the Kubuntu 16.04 release.

Comment 47 by, Oct 18 2016

This bug has been reintroduced in chrome stable 54.0.2840.59-1

Comment 48 by, Oct 19 2016

Smooth scrolling has been reintroduced to Chrome 54. Please use non-deprecated methods to reverse scrolling (eg. xmodmap is deprecated).

Comment 49 by, Jan 10 2017

This bug has been reintroduced in Chromium 55.0.2883.87, running on Xubuntu 16.04 (64-bit).

Comment 50 by, Jun 23 2017

Setting the VertScrollDelta to a negative value fixed the inverted scrolling for Chrome 59.0.3071 and Gnome apps on my Debian Jessie setup using Xfce 4.10. But I had to disable the Reverse Scroll Direction in Xfce. 

I found the solution in this thread!topic/chrome/NV9uPe1UTVI

Comment 51 by, Jul 27 2018

The best way to enable system-wide natural scrolling, including for Xinput2 apps like Chrome is to set the "libinput Natural Scrolling Enabled" property:

$ xinput list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=11   [slave  pointer  (2)]
⎜   ↳ TPPS/2 IBM TrackPoint                     id=12   [slave  pointer  (2)]
$ xinput list-props 'SynPS/2 Synaptics TouchPad'
Device 'SynPS/2 Synaptics TouchPad':
        libinput Natural Scrolling Enabled (287):       0
        libinput Natural Scrolling Enabled Default (288):       0
$ xinput set-prop 'SynPS/2 Synaptics TouchPad' 'libinput Natural Scrolling Enabled' 1

This works for me for Chrome 69.

Sign in to add a comment