Open Bug 1656644 Opened 4 years ago Updated 4 years ago

{inc} Percent row gap unexpectedly resolves (against indefinite height) when inspecting a flex item with devtools

Categories

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

defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

Details

Attachments

(2 files)

Attached file testcase 1

[ Originally reported as https://twitter.com/gavinmcfarland/status/1288890599727419397 ]

STR:

  1. Load attached testcase.
  2. Right-click one of the lime elements labeled "Item", and choose "Inspect Element"

EXPECTED RESULTS:
No red should be visible. (And the layout shouldn't change when devtools opens.)

ACTUAL RESULTS:
Red becomes visible when devtools opens. (The percent row-gap suddenly resolves to something nonzero, for no good reason, and it pushes the second row of items outside of the black border, revealing the red background underneath.)

The "expected behavior" here (with a zero-sized row-gap) comes from bug 1639627; this is a case where we're inconsistent about the outcome. I think it's because really we're inconsistent about whether we consider the inner flex container to have a definite height, for some reason. (There are two nested flex containers in the testcase.)

For the record, the original testcase from twitter is https://jsbin.com/sunecah/edit?html,css,js,output , and with that testcase, the bug is reproducible in Chrome as well though with slightly different steps. So they're similarly confused/inconsistent about whether or not the inner flex container has a definite height.

(Presumably the reason devtools triggers this is just part of some targeted layout invalidation+flush that devtools triggers in just the right way, when it gathers its data to report.)

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

Attachment

General

Created:
Updated:
Size: