[Flexbox] mini-map display is initially too small, for flex item whose "desired" flex-shrink is larger than the item's actual flex base size

RESOLVED FIXED in Firefox 65

Status

defect
P2
normal
RESOLVED FIXED
6 months ago
5 months ago

People

(Reporter: dholbert, Assigned: pbro)

Tracking

unspecified
Firefox 65

Firefox Tracking Flags

(firefox65 fixed)

Details

Attachments

(4 attachments)

[This might be the same underlying issue as bug 1504296, but I'm not sure, so I spun it off separately]

STR:
 1. Load attached testcase.
 2. Inspect the item with the label "Inspect this item"

EXPECTED RESULTS:
Minimap should show that the desired shrinkage (-266px) is more than the item can possibly shrink (its flex base size is only 200px).

ACTUAL RESULTS:
The minimap looks different on different loads, and/or when I switch between this item and the other item and back.  Its two different renderings are both incorrect.

Incorrect rendering #1:

  LOTS OF       final|basis
  BLANK SPACE        [<---------------------🔒]
  OVER HERE          |min

Incorrect rendering #2:

                final|
  [              <---🔒-----------------------]
                     |min

Expected rendering would be something like "Incorrect Rendering 2", except the arrow should probably extend to the left of the box's left edge. Or at least, all the way to the box's left edge.
See Also: → 1504296
I suspect "incorrect rendering #2" might just be the rendering of the second flex item here, rather than a misrendering of the minimap for the first flex item.

At least: the minimap looks identical to what we show for the second flex item, and it also looks roughly accurate for the second flex item.
(Assignee)

Comment 4

6 months ago
Thanks Daniel. I think I understand what's happening here. The code in FlexItemSizingOutline.js does not expect mainBaseSize + mainDeltaSize to ever be negative, however it happens with testcase 1.
Assignee: nobody → pbrosset
Status: NEW → ASSIGNED
Priority: -- → P2
(Assignee)

Comment 5

6 months ago
Previously, we would always hard-code the basis-start and final-start line names first in
the grid column template used to display the minimap.
Because there may be cases where base+delta is actually negative, we cannot do that anymore.
This fixes that by removing this hard-coding and sorting the entire array of sizes before
generating the grid column template.
The test that I added is only a few lines, but to make it simpler to write, I had to
merge doc_flexbox_simple.html and doc_flexbox_specific_cases.html, which is why you are
seeing several test changed here.
Also, to make sure the test case I added would behave the same across platforms, I used the
Ahem font, which is often use in Layout tests as it only has 1 glyph that's exactly the size
of the font-size.

Comment 7

6 months ago
Pushed by pbrosset@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/33ecf2509ce8
Stop assuming that basis+delta is always positive in the flex minimap; r=gl

Comment 8

6 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/33ecf2509ce8
Status: ASSIGNED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 65
(Assignee)

Updated

5 months ago
Duplicate of this bug: 1504296
You need to log in before you can comment on or make changes to this bug.