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

Status: VERIFIED DUPLICATE of bug 1092007

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

Description

[Thomas Wisniewski [:twisniewski]]

Attachment: 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 patch.com where sub-menus on their mobile layout are positioned off-screen (reported at https://webcompat.com/issues/25384).

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase #2

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

Comment 2

[Mats Palmgren (inactive)]

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.

Comment 3

[Mats Palmgren (inactive)]

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

Comment 4

[Daniel Holbert [:dholbert]]

I can reproduce the bug at the original site ( https://patch.com/ohio/cincinnati/lifestyle ) 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 https://webcompat.com/issues/25384#issuecomment-460440243 :)

Comment 5

[Daniel Holbert [: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:
https://jsfiddle.net/h4j62scr/
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).

Comment 6

[Daniel Holbert [:dholbert]]

(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. :))

Comment 7

[Daniel Holbert [:dholbert]]

(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, https://github.com/w3c/csswg-drafts/issues/2846 is about resolving this outline drawing difference.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (original testcase with "flex-direction: column" which is needed to trigger the relevant webcompat issue)

Here's the original testcase, fixed to exercise the actual webcompat difference on the original site (patch.com), 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.

Comment 9

[Daniel Holbert [:dholbert]]

(I verified that the patch.com layout issue is also fixed now -- see https://webcompat.com/issues/25384#issuecomment-528979375 )