Are you fingers still on the touchpad when you scroll with the mouse wheel?

Over to sahel@ to investigate.

> Are you fingers still on the touchpad when you scroll with the mouse wheel?
No, I stop touching the touchpad before using the mouse wheel.
The mouse wheel seems ineffective on that tab regardless of other [concurrent] touchpad usage.

This may be in stable channel as well.  I am on version 64 on a Pixelbook.  It is intermittent but sometimes the scrolling wheel on the mouse does not work .... reloading the website does seem to fix temporarily.  2 finger scrolling seems to always work.  I have tested in stable, beta, and dev and seeing the same issue on all channels.. this was not an issue in v63 from my knowledge.  It is not always 2 finger scrolling that breaks it as it happens when the machine is docked and I am nowhere near the touchpad .... I found that sometimes it happens when resizing the window as well.  Sometimes when on the page and the scrolling wheel is not working if you type something it will kick it back to a working state.  

Google Chrome	64.0.3282.169 (Official Build) (64-bit)
Revision	0
Platform	10176.73.0 (Official Build) stable-channel eve
Firmware Version	Google_Eve.9584.107.0
Customization ID	GOOGLE-EVE
ARC	4602931
JavaScript	V8 6.4.388.45
Flash	28.0.0.161 /opt/google/chrome/pepper/libpepflashplayer.so
User Agent	Mozilla/5.0 (X11; CrOS x86_64 10176.73.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.169 Safari/537.36

 Issue 818447  has been merged into this issue.

Please prioritize this as I have started receiving complaints from our enterprise users.  If needed I can open an enterprise case on this as well.  Please advise.

https://chromium-review.googlesource.com/961264 is a fix for a similar issue.
msw@ could you please check to see if this issue is reproducible with the fix?

I'll build ToT past that rev and push the build to a device to test, should be quick.

Nope, it's still broken on ToT Chrome at #543438 using simple-chrome on eve with a base test image at R67-10486.0.0.

 andrew.schueller@ seems like the regression that you see is more like  crbug.com/821006  since you don't need to scroll with touchpad for reproducing the bug.

re comment #9, thanks msw@ for trying the fix, I am still working on reproducing the case and I haven't been able to see it, yet.
When you scroll/fling the page, do you start wheel scrolling while the fling is still active, or do you wait for sometime between scrolling with touchpad and wheel?

I stop touching the touchpad and wait for the scroll/fling to complete before trying to use the mouse scroll wheel.
Hmm, repro is very consistent for me (now on eve too); I wonder what's different between our setups/steps.
What device are you using and what Chrome / Chrome OS versions? Have you tried other mice?

@comment 10, It is possible.  I am following both threads now ... the other thread is for Linux OS and chrome browser.

I was doing the reproducing wrong, now I can consistently reproduce it, the regression has happened between M59 and M64.

I cannot reproduce the issue on 67.0.3381.0, msw@ could you please check the issue on ToT?

I am able to reproduce on Version 67.0.3376.0 (Official Build) dev (64-bit) on the Pixelbook

re comment #16:
Thanks for trying Andrew, but what you have described in comment #3 is different from the original bug. The original bug is about scrolling with trackpad that disables wheel scrolling and what you have described in comment #3 is more like crbug.com/797708 or crbug.com/823765

 Issue 825031  has been merged into this issue.

It still repros for me fairly consistently (but not always) on 67.0.3380.0, I'll try a newer build soon.
I've updated the original steps with asterisks to achieve a more reliable repro:

(1) Plug in a mouse with a scroll wheel (I'm using a simple HP one)
(2) Open some simple tall website, eg. about:version, onemilescroll.com
(3) Verify that the mouse wheel causes the page to scroll up/down
(4) Use two finger touchpad scrolling/flinging to move the page up/down (*** scroll up and down quickly ***)
(4b) *** Wait for any scrolling to stop (the scrollbar will fade away) ***
(5) Now try the scroll the page with the mouse wheel again.
Expected: Mouse wheel works normally to scroll the page up and down.
Actual: mouse wheel doesn't do anything after two finger touchpad use.

Actually, I even found one new related odd defect:
Sometimes my next attempt to two-finger touchpad scroll after step (4b)/(5) doesn't work.

As a workaround, pressing PgUp/PgDown (or up/down) on the keyboard seems to unstick the mousewheel until the touchpad is used again.

All of my comments in #19 also pertain to 67.0.3382.0 (testing on eve)

How consistent is it? I am trying the steps on comment #19 on a pixelbook(eve board). On 67.0.3383.0 I haven't been able to reproduce it in 15+ attempts, but on 67.0.3375.0 I reproduce it easily.

With the steps in #19, I can repo 4/5 times; it only repros if I wait for the scrollbar to disappear after using two-finger scrolling on the touchpad, before using the mouse scroll wheel. I'm happy to demonstrate over VC or similar.

I used deploy_chrome to get Chrome 67.0.3382.0 on my eve with Chrome OS at 10520.0.0.
What Chrome OS version are you using? (about:version's Platform #), maybe I need to flash a later image?

I borrowed someone else's pixelbook and I don't have access to it to check, but 67-10503.0.0 is the sdk version and I downloaded a binary with the same version.

Re: Comment 20  On the product support forums, someone mentioned that pressing the CRTL key also restore scrolling. So I ran a test, and it seem any key, except un-shifted function keys (top row) will restore scrolling.

See 	825730

I borrowed the device again, the platform version is:
10503.0.0 (Official Build) dev-channel eve test

 Issue 825730  has been merged into this issue.

Comment #2 on  Issue 825730  says that the bug is not reproducible on chrome 67..0.3381.0 which is consistent with what I see. 
msw@ could you please confirm if the issue is reproducible using "10503.0.0 (Official Build) dev-channel eve test" platform version or not?

I am on Chrome 67.0.3381.0 (Official Build) dev (32-bit) on platform: 10525.0.0 (Official Build) dev-channel daisy

I can reproduce the bug very reliably. 

As per #23, I already repro'ed on 10520.0.0, so what is gained if I test an older version?
(it's a time investment to switch developer mode to dev channel, or to sync+build+run an old branch)
I can demo my repro in person/VC, or loan my device if that would be helpful for you to repro.

I am trying to find out how the two cases are different, is it a chrome issue or platform issue?

Please send the chrome variations and if it doesn't help I'll do the  "sync+build+run an old branch" since it seems like I don't have any other way of reproducing the issue.

Here are my eve's Versions and Variations:
Chromium	67.0.3382.0 (Developer Build) (64-bit)
Revision	2d3de74ea1ceac9b7b6ed8189cb02b2e66485e08-refs/heads/master@{#546195}
Platform	10520.0.0 (Official Build) dev-channel eve test
...
Variations
98ee9f3e-98ee9f3e
16e0dd70-3f4a17df
6c18ba9d-3d98b302
b1681d28-b1681d28
9041608a-3f4a17df
241fff6c-4eda1c57
1e528f0f-15305a2
b130ecb8-b130ecb8
4e072ac1-4e072ac1
125b7f68-3f4a17df
b1edbc38-cf4f6ead
1c752ce9-1c752ce9
776de70c-e0278d3d
34d450b1-3f4a17df
ed7ba060-3f4a17df
9e201a2b-3f4a17df
6eb432aa-3f4a17df
652e14d1-ab59f10a
81f9f700-3f4a17df
ceff87ec-3f4a17df
44827ee5-3f4a17df
8f1e27f-3f4a17df
b72f69e9-3f4a17df
77bbdddc-3f4a17df
ef05a96e-ef05a96e
93731dca-3f4a17df
8e3b2dc5-93702590
9e5c75f1-d1800391
2981bcb4-3f4a17df
3de1fbf2-3f4a17df
5139837c-3f4a17df
7f8176d9-3f4a17df
296e6ad7-4cfc7c42
f7217a71-b2047178
23a898eb-fc93cf74
4ea303a6-3f4a17df
b19465ab-b19465ab
bcc34a89-482e268f
12be2281-e3b158e5
d92562a9-50d7c39b
2b33233e-881ca6c9
64224f74-5087fa4a
56302f8c-2f882e70
14c5a050-61ceed18
6973a1cf-3f4a17df
72606c4f-3f4a17df
1bced4a3-d61b43f8
4932440-d21eb72d
ad6d27cc-3e870323
2a32876a-b7b6ded0
f56e0452-3f4a17df
4bc337ce-535cb40a
9a2f4e5b-3f4a17df
d747916f-d747916f
1354da85-522c33b8
17507c76-3f4a17df
494d8760-3f4a17df
3ac60855-486e2a9c
f296190c-19721340
4442aae2-a5822863
ed1d377-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-6e597ede
e7e71889-e1cc0f14
34baa302-cf4f6ead
f5fff3a2-f5fff3a2
fef2fa86-fef2fa86
d66944f7-d66944f7
587fa7b2-726d8ace
11d91db8-d93a0620
3ef088b2-3f4a17df
c982cfb2-3f4a17df
493ac2c5-2a2a9269

 Issue 830260  has been merged into this issue.

Consistently reproducible on 67.0.3376.0 and not reproducible on 67.0.3381.0 or later.

Re #35: On Chrome 67.0.3381.0 (Official Build) dev (32-bit) on platform: 10525.0.0 (Official Build) dev-channel daisy, I believe it is less frequent. It seems I have work a little harder to trigger it. I can still reliably reproduce by scrolling slow with the trackpad. It appears that moving at a fast or moderate speed does not trigger it. Every once in a while, it triggers for no obvious reason. BTW, I'm on a Samsung Series 3 Chromebook.  

sahel, I'm on 67.0.3383.0 and I can still repro

 Issue 829930  has been merged into this issue.

sahel, I have another clue. I am finding on some pages with many scrollable sections (e.g. Inbox and Calendar), sometimes scroll wheel will scroll the wrong section. Example: in Inbox, I'll have my mouse over the left-column which shows all my labels. I'll click it, drag the scroller, etc, and all events are going the left column as they should. Then I do scroll wheel and the main message view (not the left column) scrolls!

Similarly in Calendar, I've seen sometimes I try to scroll the main view and the list of calendars in the far left starts to scroll!

Point is, maybe events aren't being dropped, but just routed to the wrong place.

https://chromium-review.googlesource.com/c/chromium/src/+/1014415 is a fix for this issue.

Update on reproducing the bug:

The regression happened on 64.0.3282.0 and it consistently reproducible before browsrside fling, with browser side fling the issue is reproducible only when no fling happens after the scroll. i.e. when trouchpad scrolling doesn't have any inertial part and scrolling ends when the user lifts their fingers.

Delete comment ⚐
I tried the fix in comment 40 on 67.0.3383.0 and it fixed this bug.

However, it regresses https://bugs.chromium.org/p/chromium/issues/detail?id=717205.  That's not as big of a deal now that the UI for overscroll has changed, so I support prioritizing this bug.

Maybe we can fix this without regressing 717205 by checking Fling Start gestures for non-zero velocity when setting fling_in_progress_.

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

commit fe4b9ea5050c23b5eb03258412f02ef42798084e
Author: Sahel Sharify <sahel@chromium.org>
Date: Tue Apr 17 14:48:12 2018

Revert "Filter GestureScrollUpdate during scroll fling."

Original cl reviewed on https://chromium-review.googlesource.com/727464

Reason for revert: The original cl causes the following regression and
with browser side fling and async wheel events it's not needed anymore.

Regression: Touchpad scrolling disables wheel scrolling since GSU events
generated from wheel scrolling get filtered here:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/gesture_event_queue.cc?q=Gesture_Event_queue&dr=C&l=130

fling_in_progress_ gets reset on GFC which is received when the user
puts their fingers on touchpad, so if the user scrolls with touchpad
first and then starts a subsequent wheel scrolling no GFC will be
received after the GFS and fling_in_progress_ will be still true while
GSU events from wheel scrolling are arriving.

Bug:  817479 ,  717205 
Change-Id: I3997f756430df432aab37e5af77e1409dc8e0225
Reviewed-on: https://chromium-review.googlesource.com/1014415
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551330}
[modify] https://crrev.com/fe4b9ea5050c23b5eb03258412f02ef42798084e/content/browser/renderer_host/input/gesture_event_queue.cc
[modify] https://crrev.com/fe4b9ea5050c23b5eb03258412f02ef42798084e/content/browser/renderer_host/input/gesture_event_queue_unittest.cc

re comment 43#: With browser side fling and async wheel events, out of order GSUs don't interrupt the fling since the fling itself is handled by sending GSU events to the renderer.

i.e. the fix in https://chromium-review.googlesource.com/727464 is not needed for  717205 anymore.

717205 still affects overscroll, I was able to reproduce with the revert.  But if it doesn't affect fling, it's much lower priority.

I must have missed the overscroll regression, I don't know what I should be looking at to see the regression. Could you please explain more?

I am aware of  crbug.com/345386  which got fixed by browser side fling as well. Is this what you meant?

Sometimes on an overscroll, when you lift your fingers the GFS would be filtered and the animation would be stuck.  This was much more disruptive when we actually showed the next/previous page.  Now that we show the arrow icon, it's not so bad.  I'm also finding it much harder to reproduce now. 

I think https://chromium-review.googlesource.com/553424 fixes the case that the GFS would get stuck in the debounce queue and, my change has reverted https://chromium-review.googlesource.com/727464 which is independent from the overscroll regression, right?

Ah you're right, I conflated the two.  Maybe there's something in the overscroll logic that's causing the behavior I'm seeing.

I can confirm that your revert doesn't affect overscroll sticking- I can reproduce with or without it, but only rarely.

Great, thanks for the clarification.

Merge request for the fix in comment #44.

Reason for merge:
This fix improves the user experience on Chromebooks when users use both trackpad and wheel for scrolling.

This bug requires manual review: Reverts referenced in bugdroid comments after merge request.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Not sure if Fixed status issues will get looked at

has this fix been tested / confirmed on ToT?  It's not a M67 regression and limited to a couple of boards so may not approve.  Risk?

 Issue 828870  has been merged into this issue.

 Issue 806600  has been merged into this issue.

I have tested the fix on ToT and it resolves the issue, msw@ could you please confirm the fix on ToT?

Awaiting test confirmation on more than one board prior to merge approval.  Thx

Verified fixed on eve device with Chrome OS 68.0.3404.0 / 10612.0.0

I've seen this happen when I don't believe there was any interaction with the touchpad. A single control click did not fix the issue. I needed to first scroll on the touchpad and then do a single control click to get mouse wheel scrolling working again.

Google Chrome	65.0.3325.209 (Official Build) (64-bit)
Revision	0
Platform	10323.67.5 (Official Build) stable-channel eve
Firmware Version	Google_Eve.9584.107.0

Thanks msw@!

re comment #64: I have tried it on samus and msw@ has tried the fix on eve, do you want me to try on any specific board?

re comment #66: If you see the bug when you haven't had any interactions with the touchpad then what you see is not related to this bug. There are other bugs related to wheel scrolling please take a look at these bugs:
crbug.com/820979 or  crbug.com/828751 

Approving merge to M67 Chrome OS.

Any chance this fix can be pushed to M66.  We just rolled out 85 pixelbooks and are getting multiple reports of this issue

 Issue 836077  has been merged into this issue.

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

commit cf859e1cadf1ece236aa114715a9be9de3d364a0
Author: Sahel Sharify <sahel@chromium.org>
Date: Thu Apr 26 17:05:44 2018

Revert "Filter GestureScrollUpdate during scroll fling."

Original cl reviewed on https://chromium-review.googlesource.com/727464

Reason for revert: The original cl causes the following regression and
with browser side fling and async wheel events it's not needed anymore.

Regression: Touchpad scrolling disables wheel scrolling since GSU events
generated from wheel scrolling get filtered here:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/gesture_event_queue.cc?q=Gesture_Event_queue&dr=C&l=130

fling_in_progress_ gets reset on GFC which is received when the user
puts their fingers on touchpad, so if the user scrolls with touchpad
first and then starts a subsequent wheel scrolling no GFC will be
received after the GFS and fling_in_progress_ will be still true while
GSU events from wheel scrolling are arriving.

Bug:  817479 ,  717205 
Change-Id: I3997f756430df432aab37e5af77e1409dc8e0225
Reviewed-on: https://chromium-review.googlesource.com/1014415
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#551330}(cherry picked from commit fe4b9ea5050c23b5eb03258412f02ef42798084e)
Reviewed-on: https://chromium-review.googlesource.com/1030575
Reviewed-by: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#327}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/cf859e1cadf1ece236aa114715a9be9de3d364a0/content/browser/renderer_host/input/gesture_event_queue.cc
[modify] https://crrev.com/cf859e1cadf1ece236aa114715a9be9de3d364a0/content/browser/renderer_host/input/gesture_event_queue_unittest.cc

Merge request for M66 due to comment #69.

This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

Any update on this getting pushed to a M66 build?

I am still waiting for merge request approval for 66.

If anyone needs anything else relating to the issue please let me know.

+abdulsyed@, do we want to merge #44 into M66 in case we do a respin or would you prefer to wait until M67?

Chatting with Testing  to confirm in M67/Tot before merge 

+kathrelkeld

we could see the issue on M-66 10452.81.0 / 66.0.3359.149 build and issue is not seen on M-67 101575.22.0 / 67.0.3396.26 build.

So we can merge the change to M-66 to fix the issue in M-66 too

I agree with #80: this is ok to merge to M-66

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

commit 144d151e97463940eff5d36ee76c95925d4b8fa7
Author: Sahel Sharify <sahel@chromium.org>
Date: Wed May 02 19:43:37 2018

Merge the fix for  crbug.com/817479  to M66.

To make sure that the merge doesn't break anything, I cherry picked the
fix manually, did a clean build and ran content_unittests locally.

Revert "Filter GestureScrollUpdate during scroll fling."

Original cl reviewed on https://chromium-review.googlesource.com/727464

Reason for revert: The original cl causes the following regression and
with browser side fling and async wheel events it's not needed anymore.

Regression: Touchpad scrolling disables wheel scrolling since GSU events
generated from wheel scrolling get filtered here:
https://cs.chromium.org/chromium/src/content/browser/renderer_host/input/gesture_event_queue.cc?q=Gesture_Event_queue&dr=C&l=130

fling_in_progress_ gets reset on GFC which is received when the user
puts their fingers on touchpad, so if the user scrolls with touchpad
first and then starts a subsequent wheel scrolling no GFC will be
received after the GFS and fling_in_progress_ will be still true while
GSU events from wheel scrolling are arriving.

(cherry picked from commit fe4b9ea5050c23b5eb03258412f02ef42798084e)
TBR=dtapuska@chromium.org

Bug:  817479 ,  717205 
Change-Id: I405969389ed51bea5c64dfe82825d3e6c5840624
Reviewed-on: https://chromium-review.googlesource.com/1014415
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#551330}
Reviewed-on: https://chromium-review.googlesource.com/1040646
Reviewed-by: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#787}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/144d151e97463940eff5d36ee76c95925d4b8fa7/content/browser/renderer_host/input/gesture_event_queue.cc
[modify] https://crrev.com/144d151e97463940eff5d36ee76c95925d4b8fa7/content/browser/renderer_host/input/gesture_event_queue_unittest.cc

When will the fix get published?

The fix is merged to M66.
josafat@ could you please tell when will be the next respin on Chrome-OS?

Any update? I and others deal with this issue every day, multiple times a day. I'm on R67, by the way. Thanks.

sugupta@ the fix is merged back to M67 (Please, check comment #80.)
If you still see a problem and what you see is not related to  crbug.com/838457  please file a new bug. 

My mistake. Perhaps it is  crbug.com/838457  that I'm facing. Thanks.