Scroll bug on a specific combination of css: input with z-index at -1, wrapper on position fixed with border radius
Reported by
samy.ama...@gmail.com,
Sep 22 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Example URL: https://jsfiddle.net/eoL5eLyq/ Steps to reproduce the problem: 1. Get a wrapper and put a text input and a checkbox inside it 2. Make sure the wrapper has enough content that it is scrollable, give it a border radius and a position: fixed 3. Make the checkbox position: absolute, z-index: -1 4. Write enough text in the text input that the text is bigger than the width of the input 5. try to scroll down What is the expected behavior? The div should scroll, and the inputs therefore go up What went wrong? I get this weird bug where only the inputs scroll up, the text outside of the inputs doesn't scroll up, and then the wrapper starts "covering" the text. See screenshot of mid-scroll Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 53.0.2785.116 Channel: stable OS Version: OS X 10.11.2 Flash Version: Shockwave Flash 23.0 r0
,
Sep 29 2016
That is very odd indeed! I have a feeling that this is related to issue 645949 . In particular If I remove the border-radius it works fine but otherwise it appears as if content with z-index: -1 is being painted in the wrong layer. flackr, if this is not related assign back to me.
,
Sep 29 2016
This is not related to issue 645949 . It seems to be an issue with the composited scrolling path and border radius. It only reproduces on high dpi, when we normally promote overflow scrollers. We have an exception for border-radius https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp?sq=package:chromium&dr=CSs&rcl=1475147902&l=1521 but we promote elements which have a clipParent whenever we think we are compositing scrollers (the code was accidentally removed but is being added back in https://codereview.chromium.org/2382563002 ). I think this is what is causing the bug: We have promoted a child because it has a clipParent but we have not actually promoted the scroller.
,
Sep 29 2016
Hmmm, the bug is present for me in current stable (53.0.2785.116) on Mac OS which branched at 403382. The culprit commit you mentioned is revision 417743. In fact the issue I linked is also after branch point which is confusing. I will do a build using the patch you mentioned and will check if it is fixed.
,
Sep 29 2016
Re #4, revision 417743 was my guess as to why it works in canary - I think that it may have broken the clipping of composited descendants. I've put together what I think is a minimal repro (with comments to explain): http://jsbin.com/wiguyo/edit?html,css,js,output border-radius makes us not have composited scrolling, the composited content makes us promote the scroller in order to clip it, and the negative z-index content puts the normal flow content into the foreground layer. Then, it seems that without composited scrolling we don't move the foreground layer with the scroll.
,
Oct 5 2016
Nice repro! schenney@ do you think we should de-dup this with 645949? Also will your fix be merged with M54?
,
Oct 5 2016
My changes were never in m53 and I don't think m54 either (although I would have to check). We'll look at it again once https://codereview.chromium.org/2389293002/ lands, and maybe when we land the additional changes in https://codereview.chromium.org/2382563002. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by kojii@chromium.org
, Sep 26 2016Status: Untriaged (was: Unconfirmed)