Closed Bug 1500608 Opened Last year Closed Last year

"###!!! 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), "

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla64
Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- unaffected
firefox64 --- fixed

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

(Keywords: assertion, regression)

Attachments

(2 files)

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.
Assignee: nobody → dholbert
Status: NEW → ASSIGNED
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.
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.)
Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9217bce3d561
Don't skip the flex-item early-freeze for devtools after all. r=bradwerth
https://hg.mozilla.org/mozilla-central/rev/9217bce3d561
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
You need to log in before you can comment on or make changes to this bug.