Issue metadata
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 descriptionChrome 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!
,
Jul 18
That specific change is Chromecast only. It won't impact Windows.
,
Jul 19
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.
,
Jul 19
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".
,
Jul 23
I'm working on Windows touch right now, so if you can't find a culprit CL I'll take a look...
,
Nov 15
***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 |
|||||||||||||||||||||
Comment 1 by db...@etouch.net
, Jul 18