Closed Bug 1848512 Opened 1 year ago Closed 1 year ago

Final size of 0 for nested flexbox elements and vertical writing-mode

Categories

(Core :: Layout, defect)

Firefox 117
defect

Tracking

()

RESOLVED DUPLICATE of bug 1310551

People

(Reporter: ivanglmvc, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/115.0.0.0 Safari/537.36

Steps to reproduce:

Create an HTML layout with a flex parent element and set a direct child (flex item) also to display: flex;
Set the writing-mode of the children (flex items) of the nested flex element to a vertical value, e.g. to vertical-lr.

I set up a CodePen with the explained setup where the issue can be seen and tested:
https://codepen.io/glmvc/pen/LYdErxy

Tested in Firefox Version 116.0.2 (64-bit) and Firefox Developer Edition Version 117.0b1 on macOS Ventura (Version 13.4)

Actual results:

The layout described causes the nested flex element to have a calculated final size of 0(px).

Expected results:

The final size of the nested flex element is calculated correctly in other major browsers.

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Layout
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true

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

:dholbert, since you are the author of the regressor, bug 1454822, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Attached file Reduced test case

Attaching reduced test case.
Interestingly enough, padding: 0 is required to repro the exact behaviour, and toggling it in inspector results in the expected behaviour.

Also should be noted that if the padding was removed altogether in the testcase, ul size seems to make sense, but li contents are pushed out.

See Also: → 1310551

Thanks for linking to bug 1310551, dshin -- I think this is indeed a version of that bug, which happens to get inadvertently worked-around if we reflow the same frame several times.

Bug 1454822 was an optimization to remove some redundant reflows (or reflows that should be redundant, except in cases of known bugs like bug 1310551). So it makes sense that this would be an instance of bug 1310551, which was ~hidden until we landed bug 1454822.

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1310551
Flags: needinfo?(dholbert)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: