dynamically changing display:inline to position:relative doesn't correctly make it containing block for absolutely positioned elements
Reported by
ldavidba...@gmail.com,
Aug 25 2016
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/51.0.2704.79 Chrome/51.0.2704.79 Safari/537.36 Example URL: Steps to reproduce the problem: 1. load attached testcase What is the expected behavior? Expected behavior is that the pink box alternates every second from being in the top right corner of the page to being in the top right corner of the blue box. What went wrong? Actual behavior is that the pink box alternates every second from being in the top right corner of the page to being hidden somewhere. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 51.0.2704.79 Channel: n/a OS Version: Ubuntu 16.04 Flash Version: In the static case (the element being position:relative from the start rather than dynamically changed to it), the pink box is correctly positioned in the top right of the blue box.
,
Aug 26 2016
Able to reproduce the issue on stable version 52.0.2743.116, and Canary version 54.0.2839.2 on Windows 10 and is a non regression seen from M24 - 24.1300.0. Issue is also observed in MAC and Ubuntu OS. Untriaging it so that it gets addressed. As per above comment, this works fine on FF.
,
Aug 29 2016
Not V8 related.
,
Aug 29 2016
,
Sep 8 2016
,
Sep 8 2016
Since I am working on ng relative code, I'll take a look.
,
Sep 14 2016
I've found the core cause, unsure of how to implement the fix.
eae, szager, can you recommend a Layout code expert
Cause -- high level:
Changing relative to static does not mark abspos TARGET as needing layout.
Why:
LayoutInline does not know which children use it as a containing block,
so it does not invalidate them on styleDidChange.
What needs to happen:
1) All abspos descendants of LayoutInline element need to get reattached
to new container block.
How to code this?
Force layout on all children?
2) abspos children must be setNeedsLayout(true) again.
How to code this?
tell future containingBlock->setPosChildNeedsLayout(true),
In LayoutBlock::::insertPositionedObject
object->setNeedsLayout()
,
Sep 16 2016
I think you should look at LayoutBlock::layoutPositionedObjects() too. Also what we do in moveWithEdgeOfInlineContainerIfNecessary() is related and could be your best bet for setting the layout you're looking for.
,
Sep 16 2016
Thanks @robhogan. The fix was to remove children from containing blocks when element changes style between static->positioned. CR here if you are interested: https://codereview.chromium.org/2342173002
,
Oct 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6825fc78a249ee41df165e2a3376e4fdb9ef504b commit 6825fc78a249ee41df165e2a3376e4fdb9ef504b Author: atotic <atotic@chromium.org> Date: Sat Oct 01 21:44:01 2016 Fix #641162: LayoutInline propagate position changes to abspos descendants When inline element changed its position inline->abspos, its out-of-flow descendants did not get layout invalidated. This change forces relayout of out-of-flow descendants on position style change. BUG= 641162 Review-Url: https://codereview.chromium.org/2342173002 Cr-Commit-Position: refs/heads/master@{#422331} [add] https://crrev.com/6825fc78a249ee41df165e2a3376e4fdb9ef504b/third_party/WebKit/LayoutTests/fast/block/positioning/absolute-in-inline-dynamic.html [modify] https://crrev.com/6825fc78a249ee41df165e2a3376e4fdb9ef504b/third_party/WebKit/Source/core/layout/LayoutBlock.cpp [modify] https://crrev.com/6825fc78a249ee41df165e2a3376e4fdb9ef504b/third_party/WebKit/Source/core/layout/LayoutBlock.h [modify] https://crrev.com/6825fc78a249ee41df165e2a3376e4fdb9ef504b/third_party/WebKit/Source/core/layout/LayoutInline.cpp
,
Oct 3 2016
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ldavidba...@gmail.com
, Aug 25 2016