Closed Bug 1525083 Opened 2 years ago Closed 2 years ago

Handling of relative positioning in list items in flexboxes differs between Gecko and Blink


(Core :: Layout: Flexbox, defect, P3)




Tracking Status
firefox67 --- affected


(Reporter: twisniewski, Unassigned)



(Whiteboard: [webcompat])


(3 files)

Attached file test.html

The attached test-case has a <ul> with a single <li> containing a <div>. That div is relatively positioned at top:100%. If the <ul> is given display:flex, then Gecko increases the size of the flexbox list to contain it, while Blink does not (the <ul> remains the same height, and only its <li> becomes taller to contain the <div>).

It's unclear to me which is correct behavior per spec, but it's causing an interop issue on where sub-menus on their mobile layout are positioned off-screen (reported at

Flags: webcompat?
Attached file Testcase #2

Same as the first testcase, but with outlines replaced with background color.

I think the first testcase only demonstrates that we draw the outline
differently to Chrome. Testcase #2 shows that there isn't any sizing
differences. We align the bullet differently though, but we probably
have bugs open on that.

So I'm not sure if the testcases here accurately reflects the reported
web-compat issue.

Flags: needinfo?(twisniewski)

Also, the site geo-blocked when accessed from the EU apparently.

I can reproduce the bug at the original site ( ) in Responsive Design Mode

I'll see if I can generate a reduced testcase... There might be some time pressure to investigate here since apparently Patch is also working on fixing this internally, per :)

Flags: needinfo?(dholbert)
Flags: needinfo?(dholbert)
Priority: -- → P3
Flags: needinfo?(dholbert)

OK, so the actual difference on the original site is from a disagreement about top: 100% on the relatively-positioned element with class ".dropdown-menu". Chrome's right, and this is our bug, bug 1092007.

Chrome is disregarding that style (i.e. resolving the style to 'auto' which in the case of relpos means no-adjustment).
Firefox is honoring that style (resolving it against the height of its container).

Chrome is correct; the container in this case is a flex item whose size should be considered indefinite, because it's in an indefinite-size flex container and has an indefinite (content-based) resolved flex-basis value.

Here's a reduced testcase demonstrating the difference:
Chrome renders "Side by side" all on one line, whereas Firefox shifts "side" downwards (due to mistakenly honoring its percentage value on its top property).

Closed: 2 years ago
Flags: needinfo?(twisniewski)
Flags: needinfo?(dholbert)
Resolution: --- → DUPLICATE
Duplicate of bug: 1092007

(As it turns out, the original testcase was barely over-reduced. It only needed "flex-direction:column" on the flex container in order to reproduce the key [not-outline-related] rendering difference here. :))

(In reply to Mats Palmgren (:mats) from comment #2)

I think the first testcase only demonstrates that we draw the outline
differently to Chrome.

Incidentally, is about resolving this outline drawing difference.

Here's the original testcase, fixed to exercise the actual webcompat difference on the original site (, per comment 6.

With this adjusted testcase, I can confirm that bug 1092007 (fixed in today's nightly) did indeed address this. In prior versions of Firefox, the bullet and "test" were on two different lines, whereas in Chrome and in current Nightly, the bullet and "test" are on the same line.

(I verified that the layout issue is also fixed now -- see )

You need to log in before you can comment on or make changes to this bug.