Closed Bug 1500608 Opened Last year Closed Last year
"###!!! ASSERTION: available
Free Space's sign should match is Using Flex Grow" followed by "Assertion failure: !is Using Flex Grow (Unfrozen items can only shrink if we're distributing (negative) space with flex-shrink), "
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 email@example.com: https://hg.mozilla.org/integration/autoland/rev/9217bce3d561 Don't skip the flex-item early-freeze for devtools after all. r=bradwerth
You need to log in before you can comment on or make changes to this bug.