Issue metadata
Sign in to add a comment
|
Absolute position child of display:flex element doesn't update position when parent size changes
Reported by
corrie...@gmail.com,
Jan 28 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36 Steps to reproduce the problem: 1. Put an absolute position element with "bottom: 0" or similar in a relative position element with "height: auto" and put all of that under an element with "display: flex" 2. Do something that causes the height of the intermediary (position relative) node to change height What is the expected behavior? In the attached example, the scrollbar should be updating to stay at the bottom of the codemirror editor. What went wrong? Note that now the position absolute element renders in the wrong spot. Doing something like changing the browser window size or position absolute style to "bottom: 0.1px" instead of "bottom: 0" causes it to jump to the correct position Did this work before? N/A Does this work in other browsers? Yes Chrome version: 55.0.2883.95 Channel: n/a OS Version: OS X 10.12.2 Flash Version: Shockwave Flash 24.0 r0 We *think* it might have regressed with Chrome 52 but are unsure since that was a while ago.
,
Jan 31 2017
,
Feb 2 2017
,
Feb 7 2017
,
Feb 7 2017
Able to reproduce the issue on Mac-10.12.2 using chrome stable version 56.0.2924.87 and Reported version 55.0.2883.95. And issue not observed in Canary 58.0.3005.2 and Beta 57.0.2987.21 This is regression issue fixed in M57. Please find the Reverse bisect information as below Using the per-revision bisect providing the bisect results, Bad:: 57.0.2942.0 -- (build revision 436203) Good :57.0.2943.0 -- (build revision 436483) ChangeLog: ================ https://chromium.googlesource.com/chromium/src/+log/915e461af0dcb90d0d98b1aab614f409d8770379..9d96126f67850daf3c07586dc09fa334d592529c Review-Url: https://codereview.chromium.org/2553833002 mstensho@ could you please look into this issue if it is related to your change,else please help us in finding the appropriate owner for this issue. Note:Issue is specific to Mac. Thanks.
,
Feb 7 2017
I don't have access to any Mac, so I cannot help. If someone could come up with a testcase that fails on all platforms (or at least Linux), I can take a look.
,
Feb 13 2017
#6 - your changes fixes it - is it safe to merge it to Chrome 56?
,
Feb 13 2017
Thanks for testing! I don't think it's a good idea to merge this. The CL itself is a quite heavy refactoring, and it also depends on preceding refactoring CLs, that most likely don't exist in M56. Better wait for M57.
,
Feb 13 2017
#8 - I did not test it, I just stated the result of the reverse bisect. Got it, thank you. I guess you can mark this as fixed, then, since it is fixed in Chrome 57+ (according to the bisect). I can try BrowserStack for you, if you want to verify it before you mark it as fixed (or maybe just merge it to issue 669039 ?).
,
Feb 13 2017
Since this was apparently broken for so long (since Chrome 52?) before it got fixed, and since it's apparently fixed now, I think it's okay to just forget about Chrome 56. I trust the bisect info above, so I'll merge it into 669039. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by ericwilligers@chromium.org
, Jan 30 2017