Hi daiji@, are you sure this is regressed in 68.0.3405.0? This was fixed recently in  issue 817479  and should be fixed in 68.0.3399.2 and later (and was recently merged back to 66 and 67).

If you're still running into this then perhaps it's a separate issue...in that case, could you attach a trace to this bug using instructions here: https://www.chromium.org/developers/how-tos/submitting-a-performance-bug

I don't know if it's a regression. I plugged in my USB mouse to investigate a user-reported bug about the wheel not working, and was able to repro using this simplified case. The version is exactly what I have on that device. Are the Chrome folks not able to repro this? It might not be quite the same as your other reported issue, as your other reported issue seems to be about a single scrolling area, rather than multiple scrollable areas.

I'll try to look into the trace sometime this week when I'm at my desk.

Also affected on HP Chromebook 13 with ChromeOS 65.0.3325.209 with Bluetooth Mouse.

Performance bug uploaded: https://bugs.chromium.org/p/chromium/issues/detail?id=840226

Thanks for the repro - I can reproduce consistently on 67.0.3396.26 - we're investigating on ToT now...

 Issue 839546  has been merged into this issue.

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

 Issue 840859  has been merged into this issue.

 Issue 836281  has been merged into this issue.

 Issue 838385  has been merged into this issue.

We have another user report today from 65.0.3325.209

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

commit d0d40de018d18744c44bcab650bea7f8dfebfae4
Author: Sahel Sharify <sahel@chromium.org>
Date: Fri May 11 17:05:50 2018

Touchpad scroll shouldn't interfere with timer-based wheel scrolling.

On ChromeOS there are two different ui events for wheel scrolling:
ui:ET_SCROLL is the event type when the user scrolls with the touchpad
and ui::ET_MOUSEWHEEL is the event type when the user scrolls using an
external mouse wheel device. Wheel scroll latching works differently for
these two types of wheel scrolling:
For touchpad scrolling the sequence starts when the user touches the
touchpad (on a GFC) and ends when the user lifts their fingers (on a
GFS); While for wheel scrolling the sequence starts with the first wheel
event and ends when no wheel event has arrived for the past 500ms.

We always receive a GFC when the user puts their finger down on the
touchpad, but we receive a GFS only at the end of a scroll. So without this
cl if the user lifts their fingers from touchpad without scrolling,
scrolling with mouse wheel will get stuck to the same scrolling sequence
till the next time that the user touches the touchpad again.

This cl makes sure that these two logic for latching don't interfere
with each other: On arrival of a ui::ET_MOUSEWHEEL we reset the
touchpad scrolling state and when the user puts their finger on the
touchpad we end the timer-based latching sequence before setting the
touchpad_scroll_phase_state_.

Bug:  838457 
Test: *.ScrollingWithExternalMouseBreaksTouchpadScrollLatching
Change-Id: Id5466e5645f08e6bf44c00f4471dbb3bbf9afc89
Reviewed-on: https://chromium-review.googlesource.com/1052853
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557912}
[modify] https://crrev.com/d0d40de018d18744c44bcab650bea7f8dfebfae4/content/browser/renderer_host/input/mouse_wheel_phase_handler.cc
[modify] https://crrev.com/d0d40de018d18744c44bcab650bea7f8dfebfae4/content/browser/renderer_host/input/mouse_wheel_phase_handler.h
[modify] https://crrev.com/d0d40de018d18744c44bcab650bea7f8dfebfae4/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc
[modify] https://crrev.com/d0d40de018d18744c44bcab650bea7f8dfebfae4/content/browser/renderer_host/render_widget_host_view_event_handler.cc

Merge request for the fix in comment #17 which is first landed in 68.0.3428.0

reason for request:
There has been five reports for the issue and it's been starred by 9 users.

This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review
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

Please elaborate on testing status.   I noted the fix, but not sure if this has been tested and confirmed no newly created issues.  This is a fairly large change this late into M67 and i'd rather punt to M68 since this wasn't a M67 regression.

There is a unittest for the test and I have confirmed the fix in my local build.

daiji@ could you please test the fix in a version eaqual to or more recent than 68.0.3428.0?

Other than the change on lines 129-132 of mouse_wheel_phase_handler.cc and line 374 of render_widget_host_view_event_handler.cc the rest of the changes are comment changes or renames. I didn't separate the renaming from the logic change since I wanted to merge them both to 67. This avoids any conflicts due to renaming in case I need to merge back some other change to 67. (I am working on one more scroll related bug and I'd like to merge back the fix if I can find it in time.)

Sorry, I'm still not clear per #21.

Most of then changes are in unittest, but not all.  Nor are all limited to comments.

I need more details on testing results.  We can't merge without testing for desired and undesired impact against ToT, or similar.  Thanks

Sorry I wasn't clear enough in comment #22: What I meant was the LOGIC changes are limited to what I mentioned in comment #22 and the rest of the changes in non-unittest files are either name changes or comments. There is a whole new unittest added to test the case that I wrote the fix for.

chriswillmorris@ (reporter of  crbug.com/836281  which is merged to this issue) could you please check the latest canary to verify the fix?

Thanks

I'll check.

I haven't been using my laptop that much recently, but the issue hasn't reoccured since switching to the 'dev' channel. Would you like me to post another update later on this week?

On latest dev channel I can no longer repro this issue. It seems fixed. Thanks!

I have not seen the issue reoccur, either. Thanks for the fix.

I assume the latest dev channel you're referring to is M68, and that it would have included the merge since it was made on the 11th.  I'd like to confirm the testing performed in #28 and #29 was made with 68.0.3428 or later.  Thanks 

It is not reproducing on 68.0.3431.0 specifically. Thanks!

Approving merge to M67 Chrome OS.

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

commit b2d915dc808b91738ee2a3050e623104cdf41bbc
Author: Sahel Sharify <sahel@chromium.org>
Date: Fri May 25 21:23:25 2018

Touchpad scroll shouldn't interfere with timer-based wheel scrolling.

On ChromeOS there are two different ui events for wheel scrolling:
ui:ET_SCROLL is the event type when the user scrolls with the touchpad
and ui::ET_MOUSEWHEEL is the event type when the user scrolls using an
external mouse wheel device. Wheel scroll latching works differently for
these two types of wheel scrolling:
For touchpad scrolling the sequence starts when the user touches the
touchpad (on a GFC) and ends when the user lifts their fingers (on a
GFS); While for wheel scrolling the sequence starts with the first wheel
event and ends when no wheel event has arrived for the past 500ms.

We always receive a GFC when the user puts their finger down on the
touchpad, but we receive a GFS only at the end of a scroll. So without this
cl if the user lifts their fingers from touchpad without scrolling,
scrolling with mouse wheel will get stuck to the same scrolling sequence
till the next time that the user touches the touchpad again.

This cl makes sure that these two logic for latching don't interfere
with each other: On arrival of a ui::ET_MOUSEWHEEL we reset the
touchpad scrolling state and when the user puts their finger on the
touchpad we end the timer-based latching sequence before setting the
touchpad_scroll_phase_state_.

TBR=bokan@chromium.org,tdresser@chromium.org
(cherry picked from commit d0d40de018d18744c44bcab650bea7f8dfebfae4)

Bug:  838457 
Test: *.ScrollingWithExternalMouseBreaksTouchpadScrollLatching
Change-Id: Id5466e5645f08e6bf44c00f4471dbb3bbf9afc89
Reviewed-on: https://chromium-review.googlesource.com/1052853
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#557912}
Reviewed-on: https://chromium-review.googlesource.com/1073908
Reviewed-by: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#703}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/b2d915dc808b91738ee2a3050e623104cdf41bbc/content/browser/renderer_host/input/mouse_wheel_phase_handler.cc
[modify] https://crrev.com/b2d915dc808b91738ee2a3050e623104cdf41bbc/content/browser/renderer_host/input/mouse_wheel_phase_handler.h
[modify] https://crrev.com/b2d915dc808b91738ee2a3050e623104cdf41bbc/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc
[modify] https://crrev.com/b2d915dc808b91738ee2a3050e623104cdf41bbc/content/browser/renderer_host/render_widget_host_view_event_handler.cc

 Issue 838730  has been merged into this issue.

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

commit 5aa9d4d24062c757b4bd39e5897df3ff544b0926
Author: Sahel Sharify <sahel@chromium.org>
Date: Mon Jun 04 20:49:51 2018

Follow up cl to test properly resetting the touchpad scroll sequence.

This is a follow up cl for:
https://chromium-review.googlesource.com/c/chromium/src/+/1052853
The test added in the original cl tests that scrolling by external mouse
wheel resets the touchpad scroll sequence in mouse_wheel_phase_handler.

This cl adds an extra test to check that the external mouse scrolling
resets the touchpad scroll sequence when the user has lift their fingers
from the touchpad without doing any touchpad scroll.

Bug:  838457 
Change-Id: I612c2ea7dee0332d25abe1d326f2e17cfe227da7
Reviewed-on: https://chromium-review.googlesource.com/1077309
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#564225}
[modify] https://crrev.com/5aa9d4d24062c757b4bd39e5897df3ff544b0926/content/browser/renderer_host/input/mouse_wheel_phase_handler.h
[modify] https://crrev.com/5aa9d4d24062c757b4bd39e5897df3ff544b0926/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc

Hi! 
We have two big customers reporting similar bug on Eve and Chell, which we were able to repro with following steps - 
1. Connect external mouse
2. Open Gmail
3. Click Compose
4. Write something in email so that scrolling for the pane would appear
5. Try to scroll with external mouse
Expected behavior -
Scrolling with external mouse work for both main Gmail window and new email pane
Current behavior - 
External mouse scrolls only main window, but not new email pane, unless touchpad is used once for new email pane - then external mouse starts working.

This issue reproduces on v65-v68.0.3416.0, but not on 68.0.3437.0, so we need to know if it is the same fix which helped, and it was already merged to v67, or we need separate merge request.
Thanks!

re comment #36:
Based on the repo steps the issue that you are describing is identical to this bug and the fix (landed in comment #17) is already merged to M67 (comment #33).