I made a quick, simple html document with a scroll handler to test a bit more, and it seems all that extra scrolling doesn't seem to trigger any scroll events (other than the mouse scrolls actually performed on the Chrome window itself).

I'm attaching the html file just in case

Deleted: test.html 647 bytes

test.html 647 bytes View Download

Unable to reproduce the issue on Ubuntu 14.04 using latest 52 i.e.52.0.2724.0.
Could please review the attached screen cast and update further if anything is missed here.

Deleted: 608246_May_4.ogv 11.5 MB

608246_May_4.ogv 11.5 MB Download

Try scrolling only down or only up on the non-Chrome window? As in, not back and forth but just in a single direction.

My step 4 should've been more specific now that I read it again.

Thank you for providing more feedback. Adding requester "durga.behera@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can reproduce this issue on Ubuntu as well. I though it may be due to recent wheel gesture change but it happens event with --disable-wheel-gestures flag.

I have attached a trace showing the wheel event at 9.8seconds which was the event cause by this pattern. We are definitely getting a mouse wheel event after switch so I guess it is perhaps an aura issue.

Deleted: trace_mouse-wheel-after-switch.json.gz 410 KB

trace_mouse-wheel-after-switch.json.gz 410 KB Download

After some more investigation, I am pretty sure this is a side-effect of how X11 (or wm?) buffers and routes mouse wheels (and perhaps other mouse events). I get the same exact behaviour with any two windows e.g., two file manager windows without Chromium being involved.

Based on that I think we should close the issue as it is not a Chromium bug.

Is it really? I've only ever experienced this in Chrome. Am I actually missing something?

Actually, I just installed a few other browsers to test:

* Chrome stable (50.0.2661.94)
* Opera (37.0.2178.32)
* Vivaldi (1.1.453.52)
* And also tested with Gnome Web (3.20.1)

All the Blink-based browsers show this issue for me. No other app or browser does. I'm not sure how up-to-date Electron is, and it also probably depends on the specific app, but current Atom (1.7.3) also doesn't show this issue.

Unable to reproduce the issue as per the comment # 3 as well.
Assuming this is not a chrome specific issue as per the above comment # 7, closing it for now.
Feel free to re-open if its really an issue to look into or raise a separate one.

I've recorded a video (hopefully) demonstrating this issue, and that it doesn't affect other applications for me.

https://www.youtube.com/watch?v=5ImVgT9ndns

Also note how Chrome doesn't show the issue the first time it's tabbed to, but when tabbing back and forth between those two windows (xev and Chrome), the issue manifests itself.

I really wonder if there's something else at work since comment #7 mentions it happening with any window, but for me it only happens with Blink-based apps.

Thanks for recording the video.

I now realized that I can only reproduce this with *touchpad* scrolling and not with a regular mouse wheel. I believe what I am seeing is the touchpad fling behaviour on X11.
When I do a scroll gesture on touchpad it generated a series of mouse events after gesture ends (i.e., fling). X11 seems to route these events to the top most window at the pointer location which changes when you alt-tab. Again, this is not limited to Chrome. See attached video showing this.

Mac OS routing behaviour for fling is different, the event stream is latched to the original window and does not change after alt-tab.


nsdragon@: Do you use a regular mouse or a touchpad?

Deleted: overlapped-window-event-routing-X11.mov 21.3 MB

overlapped-window-event-routing-X11.mov 21.3 MB Download

I use a regular mouse. I have my touchpad disabled most of the time, didn't test with it at all. I'll test later today.

+ sadrul

> I use a regular mouse.
Then my repro is probably not relevant.

> I'll test later today.
1. See if you can repro with two xev window similar to my setup. That way we can see the event sequence before and after.

2. If you test with Chrome, you can use this test page to log the events: http://rbyers.github.io/eventTest.html

3. Let me know if you see any mouse events generated once you have stopped moving the wheel? The video does not really help knowing when you actually use the wheel only the generated sequence.

I'm attaching a video with a test similar to majidvp@, two overlapping xev windows, scrolling with the mouse wheel and tabbing between them. No fling happens but I can understand that that is an issue unrelated to Chrome.

Deleted: scroll-xev-2016-05-10_07.40.19.webm 9.0 MB

scroll-xev-2016-05-10_07.40.19.webm 9.0 MB Download

(Forgot to mention: No, I don't get any extra events once I have stopped moving the mouse wheel)

Also attaching another video using the eventTest page linked. This one is more interesting.

I mentioned that the extra scrolling wasn't firing additional javascript scroll events. It still doesn't, but look at the deltaY value.

Each 'scroll click' of my mouse wheel generates output with deltaY as either 53 (positive) or -53. When this issue happens, those events are shown to have deltaY of multiples of 53 or -53, depending on how far I scroll. At one point it shows a deltaY of 106, which was me performing a single mouse wheel 'scroll click' on the xev window, then alt-tabbing and doing another single click on the Chrome window.

Also, while it doesn't show in the video, scrolling up just one 'click' on xev, and then alt-tabbing and scrolling down just one 'click' on Chrome shows no output at all, as if both scroll 'clicks' had canceled each other completely.

Deleted: event-test-2016-05-10_07.45.54.webm 9.4 MB

event-test-2016-05-10_07.45.54.webm 9.4 MB Download

Here's pretty much the same test using Firefox, which works as expected (except deltaY is +3/-3 always)

Deleted: firefox.webm 7.9 MB

firefox.webm 7.9 MB Download

And this is Opera, which (mis)behaves exactly like Chrome.

Deleted: opera.webm 6.0 MB

opera.webm 6.0 MB Download

Thanks for detailed tests and valuable information. I agree that this is not a
Chrome issue.


Here are some interesting observations:

1.First test, XEV to XEV  Comparing the timestamp progressions on the first test
event timestamp before/after switch:

   * Window 1: 412452, (+9ms) 412461, (+11ms) 412472, (+15ms) 412487
   * Window 2: (+1417ms) 413889

Notice the very large jump in timestamp after switch. This suggests X11 is
buffering the event and re-dispatching it.

In this case it is always a single press/release pair not a sequence. So it is
definitely not a fling.

2. Second test, XEV to Chrome: The interesting thing here is that Chrome is
getting multiple wheel events not a single one but it is only the first one that
has a large DELTA.

Maybe this is related on how quickly the alt-tab switch happens? Longer switch
yielding to larger scroll magnitude due to multiple wheel events getting
coalesced. Just a hypothesis.

BTW, "53" is a magic number used in Blink and GTK which is the pixel movement of
each wheel tick.  See https://code.google.com/p/chromium/codesearch#chromium/src
/ui/events/event.cc&sq=package:chromium&type=cs&l=647&rcl=1462864689

3. Third test, XEV to Firefox: So FireFox is getting similar wheel events from
X11. It generates a slightly different sequence of DOM wheel events** but the
actual page behaviour (if it does not handle wheel event itself) should be the
same in theory.

** Firefox is using a constant LINE delta mode of 3 and generates multiple wheel
events per X11 event based on the scroll magnitude. while Chrome is using a
PIXEL delta mode of magnitude * 53 and generates a single wheel event per X11
event.

1. That large delay was probably me holding alt-tab for a brief moment. You can even see gnome-shell's alt-tab switcher. Not sure what the threshold is, but holding alt-tab down makes it show up, but quick presses don't.

What I can say for certainty though, is that xev is not showing any delays whatsoever. As soon as I feel the click of my mouse wheel, xev outputs the event.

2. From what I've noticed, the larger delta is correlated to the amount of scrolling done off of the Chrome window. How quickly I switch doesn't seem to affect the delta at all.

It probably would be better if I could provide tests without having to rely on the speed of my fingers or how precisely I can manage to scroll the wheel. Any idea how I could do that?

> 1. That large delay was probably me holding alt-tab for a brief moment. You can even see gnome-shell's alt-tab switcher. Not sure what the threshold is, but holding alt-tab down makes it show up, but quick presses don't.

Yes, that is what I was thinking too. It shows the input is being buffered (assuming the original wheel tick happened before alt-tab). But I am not 
sure what is buffering the input here, X server or mouse driver.

> 2. From what I've noticed, the larger delta is correlated to the amount of scrolling done off of the Chrome window. How quickly I switch doesn't seem to affect the delta at all.

Chrome scroll amount has a direct relationship to delta. The question is why the delta is so large the answer to which is most likely somewhere is X Server or mouse driver. 

I guess my hypothesis about the delta relationship with switching delay could be wrong. In anycase, X11 Input Dev folks may be the best people to help further diagnose this specially given the videos above.

> It probably would be better if I could provide tests without having to rely on the speed of my fingers or how precisely I can manage to scroll the wheel. Any idea how I could do that?

It will be helpful but I don't know how.

You should be able to write a script using xdotool.
Mousewheel is considered a click:
https://www.semicomplete.com/projects/xdotool/xdotool.xhtml

I'm not entirely sure what you mean by 'buffered'. Each of those lines corresponds to a wheel scroll event made on that window. The xev event shown on the second terminal was caused by a scroll made on the second xev window. As in, I alt-tabbed, then scrolled again.

> I alt-tabbed, then scrolled again.
Oh, I thought you are seeing a wheel event without actually scrolling. But this is not the case so you can ignore my earlier buffer comment.

As per comment #21, I made an xdotool script to try to simulate the actions that trigger this issue, but I couldn't get it to reproduce at all, i.e. Chrome scrolls just fine, there are no extremely large deltas in either direction.

I also just created a pair of ubuntu/xubuntu 16.04 VMs and tested on those and also couldn't reproduce at all, either manually or with the xdotool script.

At this point I'm convinced it's actually something particular to Arch or, more likely, to my own setup (xorg-server and xfce versions match between my main system and the 16.04 VMs, so at least the ones in ubuntu aren't the issue).

Apologies to everyone for all the time I took. I'll keep looking into this and try to report back if I figure it out.

Deleted: xdt-test 688 bytes

xdt-test 688 bytes View Download

I finally found the culprit.

If xf86-input-libinput (on Arch; xserver-xorg-input-libinput on Ubuntu) is installed, this bug manifests. Uninstalling this package and replacing it with xf86-input-evdev (or xserver-xorg-input-evdev on Ubuntu) fixes this issue completely. The evdev package is installed by default on Ubuntu and Xubuntu, and not the libinput package, which explains why I couldn't replicate this in my VM tests before.

Unfortunately the xf86-input-libinput package is necessary in gnome-shell to be able to configure mouse settings graphically, but I hope this is a matter of configuring the package properly.

I went and tried older chromium builds from here: https://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?prefix=Linux_x64/

Builds 368633 and before work fine even with xf86-input-libinput. Build 368657 is the first one to show this bug.

I *think* this is the relevant commit? https://chromium.googlesource.com/chromium/src/+/c9c1cfcd812112c7cfacbbbe2a2dacbd117b1f48

Should I open a new bug for this with the updated info?

Thanks for sticking with this and finding a potential root cause. No need to open a new bug, I updated this bug description to be more accurate.


Assigning to sadrul@ who has been a reviewer on the original patch and he can route to appropriate person.

There is a lot going in that patch that I don't know about. However, one potential thing that may be relevant is the logic for clearing ScrollClasses which happens on EntryNotify under certain conditions [1]. AFAICT, if there is a difference between libinput and evdev in this regards and we don't clear this state then the first scroll event will have an invalid scroll offset which matches the symptoms you are seeing. This is just a guess though and I could be wrong.


[1] if (xevent->type == EnterNotify &&
        xevent->xcrossing.detail != NotifyInferior &&
        xevent->xcrossing.mode != NotifyUngrab) {
       // Clear stored scroll data
      ui::DeviceDataManagerX11::GetInstance()->InvalidateScrollClasses();
 }

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

Any news on this?

The cause seems to be a difference between libinput and evdev that is not correctly handled, so this seems to be a bug in Chrome.

Atom had a similar bug that got solved by updating Electron, but I can't find the particular fix in Electron itself.
https://github.com/atom/atom/issues/12591

This is now happening in the final release of Ubuntu 17.10, which comes with libinput instead of evdev.

By default it also comes with Wayland, where this bug doesn't happen at all. But for a lot of us who are unable to use Wayland and need to fall back to X.org (due to e.g. needing nvidia driver support), this bug is now present and in full force.

I can confirm it happens too, but with slightly different repro instructions:

1) be halfway a chrome page
2) switch to another workspace (with discord on in my case)
3) scroll in the other app (discord again)
4) switch back to the chrome workspace
5) scroll in chrome
6) observe the jerk

I can't seem to reproduce this using the initial steps, but my steps seem similar enough (scroll in another window, of which the position is the same as the chrome window, albeit on another workspace) to post it in this thread instead of in a separate one.

Is there any progress with this? Still happens with Chrome 64 exactly as described.

Thomas is this something you can help us with?

Is there any updates on this? For me it's still happening on Chrome and Chromium, and also in Atom and VSCode which are electron based applications. Only when using X11, not Wayland.

Do we have any updates on this?

Is there anything I can do to help people look into this and hopefully solve it?

This bug is creeping into a good portion of my workflow now, not even Chrome. It's present also in Vivaldi, Brave and Electron (and by extension apps such as Atom, VSCode, Slack, Discord, and many more).

I'm getting the same problem on Windows 10 (even in incognito mode).

This looks very similar to issue 807187 so assigning to thomasanderson@.

FWIW, this requires specialized knowledge to fix and we don't have the resources on our team to track down bugs across all the various driver configurations on Linux so I'm not sure this will get any attention in the near term.

The best bet would be if someone external who knows this area well could contribute patches. We can provide reviews and help submitting as needed. For starters, the patch identified above (https://codereview.chromium.org/688253002) is a good starting place for where the relevant code lives.

**UI mass Triage**

We were unable to reproduce this bug as per C#0 & no update for long,we are archiving this issue. If this bug still reproduces for you on latest chrome versions(70.0.3538.110), please reopen or file a new issue. Thanks!

I am still able to reproduce the bug using steps from comment #1 in Chrome Version 72.0.3602.2 (Official Build) dev (64-bit). Ubuntu 18.10, Gnome-shell.

Just for the reference: https://github.com/Microsoft/vscode/issues/28795

Same for me, I can reproduce and it makes coding in atom very annoying :(

Since this bug is related to Mutter as well, I've opened a bug report there https://gitlab.gnome.org/GNOME/mutter/issues/401 

Please, comment or upvote so it can be investigated at GNOME side as well.