1128348 - incorrect display of flex items with absolutely positioned sibling

Status: VERIFIED DUPLICATE of bug 874718

(Firefox :: General, defect)

Description

[Ilya]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150122214805

Steps to reproduce:

1) Open an official W3C Flexbox test suite page for section 4.1 (http://test.csswg.org/harness/test/css-flexbox-1_dev/spec/css-flexbox-1/section/4.1/flexbox_absolute-atomic/format/html5/)
2) Compare the actual display with reference page.


Actual results:

There is some extra white space between two flex items as if there was another (zero-width) flex item between them.


Expected results:

The two flex item should be displayed like there were no more items in the flex container (as on reference page).

The current Flexbox spec (http://dev.w3.org/csswg/css-flexbox/#abspos-items) says: 'An absolutely-positioned child of a flex container does not participate in flex layout.' Chrome 40 displays the test page correctly (exactly like reference page).

There are similar bugs https://bugzilla.mozilla.org/show_bug.cgi?id=874718 and https://bugzilla.mozilla.org/show_bug.cgi?id=874713, but they address the static position of the absolute child, not the wrong layout of its flexible siblings.

Comment 1

[Daniel Holbert [:dholbert]]

(In reply to Ilya from comment #0)
> There are similar bugs https://bugzilla.mozilla.org/show_bug.cgi?id=874718
> and https://bugzilla.mozilla.org/show_bug.cgi?id=874713, but they address
> the static position of the absolute child, not the wrong layout of its
> flexible siblings.

Yup -- this is actually covered by bug 874718 (though I agree it's not obvious that this is the case).

When we calculate the static position, we drop a "placeholder frame" there. In a previous version of the flexbox spec's abspos-child text, it said that these "placeholders" should get explicitly wrapped in an anonymous flex item. (This is why they influence their siblings.)

As part of updating in bug 874718, we'll do away with that behavior. --> duping.

Comment 2

[Daniel Holbert [:dholbert]]

Verified locally that this was broken in Nightly 2016-10-31 & working in Nightly 2016-11-01, which means this is VERIFIED dupe of bug 865920.

(The functionality associated with bug 874718 first shipped in the 2016-11-01 nightly.)

Comment 3

[Daniel Holbert [:dholbert]]

(Sorry, bug-number-typo -- I meant to say "VERIFIED dupe of bug 874718")