1630177 - css/css-flexbox/flex-minimum-width-flex-items-013.html flaky

Status: RESOLVED DUPLICATE of bug 1316534

(Core :: Layout: Scrolling and Overflow, defect, P3)

Description

[dgrogan (chrome)]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36

Steps to reproduce:

Load http://wpt.live/css/css-flexbox/flex-minimum-width-flex-items-013.html

Actual results:

Sometimes there is a 100px wide red rectangle. Sometimes the rectangle is narrower. If the rectangle is 100px wide, resize the window and the green image that has since loaded will be repainted and the red rectangle will only be 50px wide.

Expected results:

The image should repaint when it is loaded.

This is separate from the flex behavior being tested and tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1625676

We had a similar issue in chrome. We were under-invalidating when an image loaded when it had both a width and height specified. In most cases that works but not when the image is a flex item.

Comment 1

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 2

[Cameron McCormack (:heycam)]

Thanks for filing this separately. Daniel, is this a matter of performing some more aggressive reflow in nsImageFrame::UpdateImage?

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: image for use in testcase

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (reduced)

Here's a reduced testcase.

EXPECTED RESULTS: This should show a black-bordered green rectangle.
ACTUAL RESULTS: It renders as a vertical black bar (i.e. the image ends up with a width of 0).

(If you force an incremental reflow by e.g. opening devtools or resizing the window, then that gets us to produce EXPECTED RESULTS.)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reference case 1 (using a data URI)

Here's the same testcase, but with the image included as a data URI so that it's immediately decodable & its intrinsic size is immediately available at our first layout.

This version produces "expected results", which confirms that this is indeed an issue with our handling of the "image loaded, better invalidate some stuff & reflow again" codepath.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Cameron McCormack (:heycam) from comment #2)

Daniel, is this a matter of performing some more aggressive reflow in nsImageFrame::UpdateImage?

Probably yes, something like that. I'll leave this on my needinfo queue to take a look with a debugger at some point (though other folks can feel free to snatch this if they're interested!)

Comment 7

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 8

[Ting-Yu Lin [:TYLin] (PST, UTC-7)]

The image in the test specifies both width and height. When it's used as a flex item, we shouldn't optimize the reflow out when its intrinsic image ratio / size is known (after the images is decoded). The flakiness is fixed by Bug 1316534 Part 2, and the test is passed by Bug 1316534 Part 5.