image with max-width: 100% in overflow: auto has unstable layout on resize
Reported by
rp...@etouch.net,
Nov 7 2017
|
||||
Issue descriptionVersion: 64.0.3260.2 (32/64-bit)05d1d20e2db6d594b98fe87d7aa500f22aba70a6-refs/branch-heads/3260@{#3} OS: Windows (7,8,8.1,10),Linux (14.04 LTS),Mac OS X(10.12.6,10.13.1) What steps will reproduce the problem? 1. Launch chrome, navigate to NTP and open devtools. 2. Now go to 'Sources' section and expand 'images/branding/googlelogo' and click on 'googlelogo_color' to open image in RHS window 3. Now drag image window upwards slowly till you see 'Vertical' scroll bar,observe Actual: Vertical scroll bar disappears after slowly dragging window upwards Expected: Vertical scroll bar should not disappear after slowly dragging window upwards This is regression issue, broken in ‘M 56’ and will below is the bisect info : Good build: 56.0.2897.0 (Revision: 426674). Bad build: 56.0.2897.0 (Revision: 426989). You are probably looking for a change made after 426806 (known good), but no lat er than 426807 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/75daa868751b28b3bad9dcc033198c201129ae7d..bf81e57ced894452410821516aa5eb94f0eb3d97 From the CL above, assigning the issue to the concern owner @eseckler- 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. Suspect : https://chromium.googlesource.com/chromium/src/+/bf81e57ced894452410821516aa5eb94f0eb3d97 Thanks!
,
Nov 14 2017
+skobes Testing on TOT, it seems that the scrollbar existence calculation toggles back and forth between needed/not needed because the image is resized according to the width of the PLSA. With non-overlay bars, the width shrinks when the scrollbar is added. As a result, the picture is shrunken, thus the vertical overflow disappears and we remove the bar again. Generally, I believe we try to avoid this by freezing the scrollbars when doing the relayout [2] after adding/removing scrollbars. However, during the next subsequent layout (e.g. after PLSA size changes again), the effect is the opposite as in the previous one, since the bar is no longer frozen. I'm not sure how my code change would have affected this - I would have expected the same effect previously. Testing on 426673 from [2], I can also repro this even before my change. Steve, do you have any suggestions - is this WAI? [1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp?type=cs&q=in_overflow_relayout&sq=package:chromium&l=897 [2] https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Linux_x64/426673/
,
Nov 14 2017
,
Nov 14 2017
Agreed, this does not seem related to r426807. I reran the bisect and got a different range: https://chromium.googlesource.com/chromium/src/+log/3f0c158f52..dffd77291a From that range a likely culprit is r426604, but removing the "contain" styles from those files on trunk doesn't fix it (and if "contain" is broken we should fix it in layout anyway). Also I can repro on trunk without "contain": https://output.jsbin.com/sexayev Hit Shrink until scrollbar thumb appears, then Grow - you end up in a state where there is overflow but no scrollbar. This is part of a class of bugs related to scrollbar existence feedback loops / hysteresis, which szager and pdr have looked at in the past.
,
Jan 25 2018
I was still able to reproduce the bug on Mac with 66.0.3331.0 (Official Build) canary (64-bit) version. Any updates on this issue? szager@ please take a look. |
||||
►
Sign in to add a comment |
||||
Comment 1 by rp...@etouch.net
, Nov 7 2017