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

Issue 864958 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: [Downloads] Unwanted page horizontally auto scrolled after tapping on 'More actions' icon.

Reported by db...@etouch.net, Jul 18

Issue description

Chrome Version: 68.0.3440.68 (Official Build) Revision d2ca6001e233a025f2e51e7b97ca8fade5cb6a18-refs/branch-heads/3440@{#710}(32/64 bit)
OS: Windows(10) Touch device

What steps will reproduce the problem?
(1) Launch chrome, navigate to chrome://downloads page
(2) Perform pinch to zoom and then tap on 'More actions' icon.
(3) Observe

Actual: Unwanted page horizontally auto scrolled after tapping on 'More actions' icon.

Expected: Page should not autos crolled after tapping on 'More actions' icon and More options overlay should seen.

This is a regression issue, broken in 'M66', below is bisect info:

Good Build:66.0.3352.0(Revision:538314)
Bad Build:66.0.3353.0(Revision:538677)

ChangeLog info:
https://chromium.googlesource.com/chromium/src/+log/66.0.3352.0..66.0.3353.0?pretty=fuller&n=10000

Suspect: r538601 ?

@dnicoara: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: 
1. Unable to narrow down range as getting all Bad builds from tool hence providing suspect from CL.
2. Issue is touch specific and does not reproduce on Mac(10.12.6, 10.13.1, 10.13.6, 10.14) and Linux(14.04) OS

Thank You!
 

 
Actual_Touch.mp4
310 KB View Download
Expected_Touch.mp4
298 KB View Download
Summary: Regression: [Downloads] Unwanted page horizontally auto scrolled after tapping on 'More actions' icon. (was: Regression: [Bookmarks] Unwanted page horizontally auto scrolled after tapping on 'More actions' icon.)
Cc: csmartdalton@chromium.org
Owner: ----
Status: Unconfirmed (was: Assigned)
That specific change is Chromecast only. It won't impact Windows.
Labels: -hasbisect-per-revision hasbisect
Owner: hta@chromium.org
Status: Assigned (was: Unconfirmed)
Update: 

Rebisected for the above issue and getting below bisect range:

You are probably looking for a change made after 538382 (known good), but no later than 538384 (first known bad).
CHANGELOG URL:

https://chromium.googlesource.com/chromium/src/+log/3646cda1893920f7b32df8aeebeeff12aa83098e..bb2329a3a39191edeb7bbcccb9d0323df7039472

Suspect: r538384?

@hta: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Owner: ----
Status: Available (was: Assigned)
Not my bug. That CL added a check, it didn't change any behavior (except CHECKing if the state was corrupted)

Since the other CL seems likely to be non-sticky (a rollback of an LKGR is usually followed by a roll-forward pretty soon after) - might the bug be flaky?

Changing back to "available".

Cc: bsep@chromium.org
I'm working on Windows touch right now, so if you can't find a culprit CL I'll take a look...
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
***Mass UI Triage***

Just to update: 
Still we are able to reproduce the issue on Latest canary #72.0.3610.0 on Windows-10(Touch device) OS. 

@bsep: Could you please take a look into this issue.

Thank you.

Sign in to add a comment