1828977 - Flex containers sometimes draw their border-bottom at the top of the next column

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

As of bug 1827582, "auto"-sized flex containers with overflowing content sometimes draw their block-end border at the top of the next column, in a way that seems potentially broken.

This is new behavior that (I think) will be introduced when the patch lands for bug 1827582 (if we land the patch as-it-currently-stands there). However, I found at least one case where we do a similar thing for a display:block container (which is also arguably a bug); and Chrome does similar things in some cases. So I'm spinning off this bug for further thought rather than holding up bug 1827582 on sorting this out.

I'll post a few testcases here for discussion/investigation. Side note: I'll be zeroing out border-top on the fragmented containers here to make it easier to compare Firefox vs. Chromium -- if there's a nonzero border-top, that makes Chromium push overly-tall unfragmentable children to the next column (where they fit slightly better), whereas Firefox does not push in that case; and that behavior difference isn't what I want to focus on here.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: tall img and/or div, inside auto-height flex container, inside multicol

Here's the main testcase where I think our behavior is changing in bug 1827582.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: tall img and/or div, inside auto-height block container, inside multicol

Here's a testcase with a block container (and block-level children).

(Note: one key difference that makes this not-directly-comparable to the previous testcase is: in the "img and a div" subtests here, the img/div are stacked vertically, div-below-the-img, rather than being side by side.)

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing testcase 1 in Firefox without vs. with bug 1827582's patch, vs. Chrome

Here's a testcase comparing Firefox before bug 1827582's patch (left) vs. with bug 1827582's patch (center) vs. Chrome (right).

Red arrows indicate where one build differs from the others.

As you can see:

• Chrome seems happier to push the border-bottom to the top of the next column (e.g. in the very first case)
• in the case with unconstrained-height flex container and a tall img and a div, all three builds are different. (Chrome seems to grow the flex container to fit the expanded auto-height, which maybe seems like a good idea?)
• in the final case (img + div with max-height), bug 1827582's patch actually makes us more-similar to Chrome (pushing the border to the top of the second column), though it's not obvious if that's a good thing or just a newly shared quirk.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing testcase 2 in Firefox vs. Chrome

For completeness: here's a screenshot comparing testcase 2 (no flex involved) in Firefox vs. Chrome. (No need to compare with/without the bug 1827582 path here, since that patch is only relevant to cases involving flexbox.)

As with the testcase-1 screenshot, Chrome seems happy to push the bottom-border to the second column in the just-an-img case (the tall-unfragmentable-thing scenario).

In the very final case, where we have a max-height constraint on the container and a tall img and tall div child, Firefox and Chrome both seem to have bugs:

• Firefox unnecessarily (?) draws a thin strip of the container in the second column, followed by the border-bottom in the 3rd column.
• Chrome doesn't draw the border-bottom at all (!)

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

:TYLin, since you are the author of the regressor, bug 1827582, could you take a look?

For more information, please visit auto_nag documentation.

Comment 6

[Daniel Holbert [:dholbert]]

(note: I tested WebKit i.e. Safari 16.4 on these testcases, too, but it's not-particularly-interesting since they appear to just use a "slicing" approach for the tall image in both testcases -- they don't do "sophisticated" fragmentation with fragmentation-avoidance-for-monolithic-elements.)

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1827582

Comment 8

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

I spin off bug 1830192 to fix the block container (the last subtest in testcase 2).

Re comment 3 about the observation of testcase 1:

in the final case (img + div with max-height), bug 1827582's patch actually makes us more-similar to Chrome (pushing the border to the top of the second column), though it's not obvious if that's a good thing or just a newly shared quirk.

I feel after my patch bug 1827582, we are more consistent with where the block-end border's gets drawn. That is,

• if the children are complete in the first column (just an image), we draw the border in the first column.
• if the children are not complete in the first column (img + div), we draw the border in the second column.

Comment 9

[Pascal Chevrel:pascalc]

Daniel, is that bug likely to cause webcompat problems?

Comment 10

[Frank Griffith Jr]

Discussed with Ting Yu. Will be added to work object Epic https://mozilla-hub.atlassian.net/browse/FFXP-1759

Comment 11

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

(In reply to Pascal Chevrel:pascalc from comment #9)

Daniel, is that bug likely to cause webcompat problems?

I don't feel this can cause webcompat problem because the testcases are exercising edge case scenario with an unbreakable flex item in a column container with a short column height, which is rare in real sites.

Comment 12

[Daniel Holbert [:dholbert]]

I agree with TYLin -- this is unlikely to cause webcompat issues. This bug is just about making sure we're internally consistent between edge cases (but the edge cases here are quite rare in real content & users would be unlikely to notice or care which behavior we happen to have).

Comment 13

[Pascal Chevrel:pascalc]

Thanks!

Comment 14

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Per comment 11 & comment 12, this is not a severe bug and I'm not working on this issue right now, so unassigned myself to reflect to reality.

Comment 15

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

Attachment: Screenshot comparison Firefox Nightly 124 (2024-02-11) vs Chrome 123.png

After bug 1744363, we now can grow the auto-height flex container to fit the expanded flex items. So the third subtest in Testcase 1 is OK.

I made a new screenshot comparison with Chrome. From left to right is: Testcase 1 & 2 in Firefox, Testcase 1 & 2 in Chrome.

Comment 16

[Ting-Yu Lin [:TYLin] (PST, UTC-8)]

As summarize in comment 8, we are now consistent with where block-end border's gets drawn. Though it is different from Chrome, I don't feel our behavior is wrong. Since this is unlikely to cause webcompat issue, I'm going to close this.