All users were logged out of Bugzilla on October 13th, 2018

Weird behaviour with an :after with position absolute and flexbox

VERIFIED DUPLICATE of bug 874718

Status

()

VERIFIED DUPLICATE of bug 874718
3 years ago
2 years ago

People

(Reporter: Phyks, Unassigned)

Tracking

41 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8665568 [details]
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

3 years ago
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 874718
(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.)
(Reporter)

Comment 4

3 years ago
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.
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.)
Status: RESOLVED → VERIFIED
(Sorry, bug-number-typo -- I meant to say "VERIFIED dupe of bug 874718")
You need to log in before you can comment on or make changes to this bug.