For a container with a flex column direction and flex grow items, there are cases where if a max height is applied to one of its items the delta outline for that item does not show correctly. Example: data:text/html,<div style="display:flex;flex-direction:column"><div style="flex-grow:1;height:500px;max-height:300px"></div><div style="flex-grow:1;height:500px;"></div></div>
Assignee: nobody → mtigley
Status: NEW → ASSIGNED
Here is a better example to test this: data:text/html,<div style="display: flex;flex-direction: column;width: 100px;"><div style="height:75px;max-height:30px;background-color: blue;"></div><div style="flex-grow:1;height:50px;background-color: purple;"></div><div style="height: 10px;background-color: green;"></div></div>
Hi Daniel, I'm having trouble interpreting what is happening in the flex outline here. Perhaps you would have a better understanding of this case here. My first idea was that the delta outline should extend all the way to the final size. However, looking at the flexibility section the delta outline seems to be correct.
Attachment #9019789 - Attachment is obsolete: true
I believe the mainDeltaSize is meant to represent how much the flex item wanted to flex in the final run of the flexbox layout loop that it participated in. So e.g. in your example in comment 2, if you highlight the first flex item to show the "minimap", the UI there is meant to indicate that: - the flexbox algorithm wanted to shrink the item by 25px (that was its "fair share" of flex shrinkage) - But that wasn't enough to reach its minimum, so we clamped it to an even-smaller size (independently of how much it wanted to flex).
Put another way: your example in comment 2 is a case where the flex-algorithm-provided delta doesn't get us into the item's [min,max] range. It's perhaps simpler to reason about in cases where the delta *overshoots* the item's [min,max] range, like here: data:text/html,<div style="display:flex;width:100px;border:1px solid black"><div style="flex: 1; max-width: 30px; background: yellow">aa</div> (The diagram in this ^^ case is intending to show that the item was assigned 100px of space in the flex algorithm -- i.e. all of the container's space -- but that delta puts it beyond its max-width, so it was clamped and didn't actually receive all of that delta.) So I don't think there's actually a bug here, except that we could perhaps do a better job of making our graphic comprehensible. :) (not to suggest that that's easy)
Actually, I do see one bug here -- we don't show the message... "The item was clamped to its maximum size" ...in your testcase from comment 2, but we should. That would help explain what's going on here. In contrast, we *do* show that message in my example from comment 4. We probably should be reporting that message in any scenario where we draw the "lock" icon (which is how we graphically indicate clamping). (Under the hood, we do note the fact that we were clamped via the new per-flex-item data added in bug 1498273.) Would you like to morph this bug to cover that issue? Or feel free to do whatever you like with this bug, but I do want to be sure we track that issue somewhere.
Thank you for the explanations. I definitely understand this much better now :) I'll morph this bug to address the issue you identified. Again, thanks for your help!
Summary: The delta outline is sometimes incorrect for a flex column direction container when there are multiple flex items → Make sure that a clamped flex item reports that its maximum/minimum size has been clamped.
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/01d04147fd94 Maximum sizing section should also consider if a max-clamped flex item shrank. r=pbro
You need to log in before you can comment on or make changes to this bug.