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

Issue 828751 link

Starred by 6 users

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

scroll with overflow-x hangs

Reported by srides...@gmail.com, Apr 4 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
1. create a scrollable list (with overflow-x: hidden)
2. scroll to the bottom
3. scroll some more to the bottom
4. spam scrolling some more to the bottom
5. Realize you can't scroll up anymore for a few seconds
6. Oh wow, we can scroll up all of a sudden now!

What is the expected behavior?
I made a dropdown-menu. As you can see it is scrollable because of the overflow-x:hidden.

In IE9 it works as expected. But when I try it in Chrome, you can scroll till the bottom, and if you scroll a few times more to the bottom, the list will hang for a second and scrolls only then to the top.

What went wrong?
Here is a plnkr: http://plnkr.co/edit/vwCIau4STpJjWkVJxcar
And here is the stackoverflow issue: https://stackoverflow.com/questions/49645153/scroll-hangs-with-bootstrap-dropdown-menu

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 65.0.3325.181  Channel: stable
OS Version: 10.0
Flash Version:
 

Comment 1 by woxxom@gmail.com, Apr 4 2018

Bisect info: 523805 (good) - 523813 (bad)
https://chromium.googlesource.com/chromium/src/+log/6aee1571..bd229821?pretty=fuller
Suspecting r523809 = e7015d5af038b1541c08b087c3837971c89b7ff1 = https://crrev.com/c/820334 by sahel@chromium.org
"Scroll latching timer timeout is 500ms and Mouse move breaks latching."
Landed in 65.0.3294.0

Note, it's important not to move the mouse while scrolling down in steps 2-4, and scroll up immediately after step 4.
Components: Blink>Scroll
Labels: -Type-Bug OS-Linux Type-Bug-Regression
Owner: sahel@chromium.org
Status: Assigned (was: Unconfirmed)
Can reproduce on linux as well.
Cc: sindhu.chelamcherla@chromium.org
 Issue 828943  has been merged into this issue.

Comment 4 by tge...@gmail.com, Apr 5 2018

Same issue when "spam scrolling" upwards and then trying to scroll down.

Comment 5 by sahel@chromium.org, Apr 6 2018

Cc: sahel@chromium.org susan.boorgula@chromium.org
 Issue 826601  has been merged into this issue.
Project Member

Comment 6 by bugdroid1@chromium.org, Apr 11 2018

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

commit 81487d859688a8121fc415d258bfb845a0a07c8b
Author: Sahel Sharify <sahel@chromium.org>
Date: Wed Apr 11 00:43:34 2018

Break latching if scrollable is at extent and scroll direction changes.

This cl changes timer-based wheel scroll latching to start a new scroll
sequence when no GSU from the current scroll sequence is consumed and
the coming wheel event has different scroll delta direction(s).

The reason for this fix is the following scenario:
Consider a scrollable div currently at its extent inside an unscrollable
viewport. If the user starts scrolling the div downward, the scrolling
will latch to the viewport and if there is no rubber-banding or glow
effect the user wouldn't notice this. Then if the user decides to scroll
the div upward within the same scroll sequence, the viewport will try to
scroll upward and again due to lack of overscroll notion the user would
see the scroll as ignored.

With this change the user would see the upward scrolling since direction
change would break the timer based latching and the new scroll sequence
will latch to the div.

Test: *.TimerBasedLatchingBreaksWithDirectionChange
Bug:  828751 
Change-Id: I0a709aecc1363759a3b0e0622bac8cad72666014
Reviewed-on: https://chromium-review.googlesource.com/998316
Commit-Queue: Sahel Sharifymoghaddam <sahel@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Timothy Dresser <tdresser@chromium.org>
Reviewed-by: Navid Zolghadr <nzolghadr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549701}
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/input/mouse_wheel_phase_handler.cc
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/input/mouse_wheel_phase_handler.h
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/render_widget_host_view_android.cc
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/render_widget_host_view_event_handler.cc
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/render_widget_host_view_event_handler.h
[modify] https://crrev.com/81487d859688a8121fc415d258bfb845a0a07c8b/content/browser/renderer_host/render_widget_host_view_mac.mm

Comment 7 by sahel@chromium.org, Apr 11 2018

Labels: Merge-Request-66
merge request for the fix in comment #6.

The reason for merge request:
This change improves user scrolling behavior on platforms that doesn't show overscrolling (no rubber-banding or glow effect).
Project Member

Comment 8 by sheriffbot@chromium.org, Apr 11 2018

Labels: -Merge-Request-66 Merge-Review-66 Hotlist-Merge-Review
This bug requires manual review: We are only 5 days from stable.
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

Comment 9 by sahel@chromium.org, Apr 11 2018

Status: Fixed (was: Assigned)
How safe is this merge? Has this landed in Canary? My recommendation is to wait until M67 for this fix. 

Comment 11 by sahel@chromium.org, Apr 12 2018

The fix has a test coverage, and it is first landed in today's canary: 67.0.3395.0

Since there are at least 3 bug reports for the issue (there might be other duplicate bugs with general titles like wheel scrolling doesn't work or wheel scrolling stops working, etc) I am inclined to merge the fix to 66 and I am confident that the fix won't cause any regressions.

But if you strongly advise waiting for M67, it is fine with me.


Labels: -Merge-Review-66 Merge-Approved-66
Approving this merge to M66. Branch:3359
Project Member

Comment 13 by bugdroid1@chromium.org, Apr 13 2018

Labels: -merge-approved-66 merge-merged-3359
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2129bc78426ff8d34d625e79bca1a6187625232b

commit 2129bc78426ff8d34d625e79bca1a6187625232b
Author: Sahel Sharify <sahel@chromium.org>
Date: Fri Apr 13 20:16:19 2018

Merge to M66 after resolving conflicts.

Cherry picked 81487d859688a8121fc415d258bfb845a0a07c8b

original cl reviewed on:
https://chromium-review.googlesource.com/998316

TBR=dtapuska@chromium.org,tdresser@chromium.org,nzolghadr@chromium.org

Bug:  828751 
Change-Id: I8dbcf59df805355eba730e467fa84b564181a822
Reviewed-on: https://chromium-review.googlesource.com/1012759
Reviewed-by: Sahel Sharifymoghaddam <sahel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#706}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/input/mouse_wheel_phase_handler.cc
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/input/mouse_wheel_phase_handler.h
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/render_widget_host_view_android.cc
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/render_widget_host_view_aura.cc
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/render_widget_host_view_aura_unittest.cc
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/render_widget_host_view_event_handler.cc
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/render_widget_host_view_event_handler.h
[modify] https://crrev.com/2129bc78426ff8d34d625e79bca1a6187625232b/content/browser/renderer_host/render_widget_host_view_mac.mm

Comment 14 Deleted

Tried to verify this issue as per the steps mentioned in the duped  issue 828943  . I was able to reproduce that issue on the reported version but somehow doesn't repro now on the same version. Hence unable to verify the fix on latest stable 66.0.3359.117.

@sahel: Please help in verifying the fix on latest stable 67.0.3359.117.

Thanks!
Labels: -Needs-Feedback Verified-66.0.3359.117
sahel@, thank you so much for verifying the above fix on Chrome Stable RC#66.0.3359.117.

Sign in to add a comment