New issue
Advanced search Search tips

Issue 661674 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Blink incorrectly moves static position of abspos flex child, if there's raw text next to it

Project Member Reported by dholb...@gmail.com, Nov 2 2016

Issue description

Version: Chrome 56.0.2906.0 dev (64-bit)
OS: Ubuntu 16.10

What steps will reproduce the problem?
(1) Visit https://jsfiddle.net/m2874knm/

What is the expected output?
 No red should be visible. (The blue element should be at its container's top-left corner.)

What do you see instead?
 Red is visible. Specifically: the blue element seems to be pushed down by the "hello" text, revealing the container's red background.

Please use labels and text to provide additional information.
If I remove the "hello" text, then I get "expected output". But this text really shouldn't make a difference for the positioning of the blue abspos element. Abspos children are supposed to get their static position in a way that's not influenced by the in-flow children.

I *think* what's happening here is that Blink is (incorrectly) grouping the abpos child to be inside of the raw text's anonymous flex item. I'll post another testcase to demonstrate this more clearly.
 

Comment 1 by dholb...@gmail.com, Nov 2 2016

Components: Blink>Layout>Flexbox

Comment 2 by dholb...@gmail.com, Nov 2 2016

Second testcase:  https://jsfiddle.net/jymwcpk6/

Expected output (for this testcase):
 In both boxes, the "abs" blue element should be at the bottom of its container.

Actual output:
 In the second box (the one with RAW TEXT), the "abs" blue element is grouped up alongside the text, and is not aligned at the bottom.

I think this demonstrates that abspos flex children are being improperly grouped into adjacent anonymous flex items (the wrapper-blocks that get formed around raw text inside of a flex container).

Comment 3 by dholb...@gmail.com, Nov 2 2016

MS Edge 14 & current Firefox Nightly 52 both give "expected output" on both testcases here, BTW.

Comment 4 by e...@chromium.org, Nov 4 2016

Labels: -Pri-3 Pri-2
Owner: cbiesin...@chromium.org
Status: Assigned (was: Untriaged)

Comment 5 by e...@chromium.org, May 21 2018

Status: Fixed (was: Assigned)
Now works as expected.

Sign in to add a comment