1208187 - Weird behaviour with an :after with position absolute and flexbox

Status: VERIFIED DUPLICATE of bug 874718

(Firefox :: Untriaged, defect)

Description

[Lucas Verney [:Phyks]]

Attachment: test.html

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150923042249

Steps to reproduce:

Hi,

Attached is a small code to reproduce a problem I noticed in Framework7 (www.idangero.us/framework7/) rendered with Firefox.

The "columns" made this way are not aligned one on top of another.

On the contrary, if I open the same file with Chromium, it is rendered as expected, in a tabular way.

I am not sure what is the correct way to render it, but I would have expected a render à la Chromium, and noticed the difference between the two.

Thanks

Comment 1

[Élie Michel]

I noticed the same thing.

To be clear, the issue comes from the presence of an *empty* `::after` node in a flexbox display.

Although this node has no content, some place is reserved for it, which looks weird.

Comment 2

[Daniel Holbert [:dholbert]]

Yup, this is bug 874718.  What happens (as required by old CSS flexbox spec text) is that the absolutely-positioned element drops a "placeholder" box, which gets wrapped in an anonymous flex item. So your first flex container has 4 flex items -- not 3 as you expect.

The css flexbox spec has changed, though, so that this behavior is no longer correct. We'll fix that in bug 874718.

Comment 3

[Daniel Holbert [:dholbert]]

(In the meantime, to work around this inconsistency, it's probably best to avoid having absolutely positioned elements (including ::after-generated pseudo-elements) as direct children of a flex container, if possible.)

Comment 4

[Lucas Verney [:Phyks]]

Ok, thanks!

Working around by modifying the code is not really an option, as this is code from some framework that I cannot really modify. Will follow the duplicate bug.

Comment 5

[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 6

[Daniel Holbert [:dholbert]]

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