1500608 - "###!!! ASSERTION: availableFreeSpace's sign should match isUsingFlexGrow" followed by "Assertion failure: !isUsingFlexGrow (Unfrozen items can only shrink if we're distributing (negative) space with flex-shrink), "

Status: RESOLVED FIXED

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

Description

[Daniel Holbert [:dholbert]]

STR:
 0. Be using a debug build.
 1. Load attached testcase.
 2. Inspect the flex container.  (You might need to click its flexbox flex badge)

ACTUAL RESULTS:
###!!! ASSERTION: availableFreeSpace's sign should match isUsingFlexGrow: '(isUsingFlexGrow && availableFreeSpace >= 0) || (!isUsingFlexGrow && availableFreeSpace <= 0)', file /scratch/work/builds/mozilla-central/mozilla/layout/generic/nsFlexContainerFrame.cpp, line 2701

Assertion failure: !isUsingFlexGrow (Unfrozen items can only shrink if we're distributing (negative) space with flex-shrink), at /scratch/work/builds/mozilla-central/mozilla/layout/generic/nsFlexContainerFrame.cpp:2894

Pretty sure this is a recent regression from bug 1499542.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

So in bug 1499542, we wanted to handle flex items like:
  <div style="display:flex; width: 1000px"> <!-- wheee so much space -->
    <div style="flex-grow:1; flex-basis:50px; max-width:40px"></div>
    ...
  </div>

For most flex items, we try to show a "desired" delta that the flex layout algorithm wants to grow the item, before it's clamped (if it's even clamped).

Now, for *this* item, technically the flex layout algorithm "freezes" it at its max-width up-front (since we're growing flex items, and this flex item's base size is already larger than its max-width). But the goal of bug 1499542 was to pretend that doesn't happen, and do an extra "known-bogus" loop of the flex algorithm, to see how much this flex item would've grown if we hadn't clamped it early on.

But this is problematic for cases where the flex item's clamped vs. unclamped size would change the size of the available space, e.g. in the attached testcase.  In that kind of scenario, this bogus just-pretend first loop has trouble because the item doesn't really want to grow at all.

So really, I'm starting to think we should just revert bug 1499542 part 1, and (for now) be OK with reporting a "desired" mainSizeDelta of 0 for these early-frozen items.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: Bug 1500608: Don't skip the flex-item early-freeze for devtools after all.

This patch basically reverts the functional part of changeset 52bd865d757c.
I'd optimistically hoped we could skip this early-freeze in order to compute &
report a bit more "potential flexing" information via devtools.  Bbut it turns
out that breaks assertions & produces bogus information for flex items whose
base size vs. min/max-clamped "hypothetical" sizes are very
different. (Specifically: it produces nonsense for flex items whose base sizes,
if unclamped, would reverse the directionality of flexing.)

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9217bce3d561
Don't skip the flex-item early-freeze for devtools after all. r=bradwerth

Comment 5

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/9217bce3d561