1739260 - hang with floats and aspect-ratio

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect)

Description

[Daniel Holbert [:dholbert] (PTO until Jun 29)]

Attachment: testcase 1 (warning, hangs Firefox)

STR:

1. Load attached testcase.

ACTUAL RESULTS:
The content process hangs indefinitely (or at least for > 30 seconds, which is as long as I waited).

EXPECTED RESULTS:
No such hang.

NOTES:
Credit to iank from the Chrome team for sending me this testcase.

Here's a profile (again, just for ~30 seconds of the hang): https://share.firefox.dev/3q4BVf3

Comment 1

[Daniel Holbert [:dholbert] (PTO until Jun 29)]

A pernosco session of this issue (with me ultimately killing Firefox via Ctrl+C) is available at https://pernos.co/debug/5Mxl-UA3ee3zTo2IWBJpzw/index.html

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:boris, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Boris Chiou [:boris]]

My initial investigation for this bug:
nsIFrame::ComputeSize() (called when we construct childReflowInput) return (0, 0) for the element with aspect-ratio when doing reflow [1]. When we try to put this element into the bottom-right available area, our flow available size is (0, 3000), so we use 0 as its available inline size in nsIFrame::ComputeSize(), and use 1/1 aspect-ratio, so the result is (0, 0). And then we stay in the do-while loop [2] forever. Still trying to figure why we don't break this loop and what is the expected behavior for this case.

[1] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3842-3844
[2] https://searchfox.org/mozilla-central/rev/5e15e00fa247cba5b765727496619bf9010ed162/layout/generic/nsBlockFrame.cpp#3858-3978

Comment 4

[Daniel Holbert [:dholbert] (PTO until Jun 29)]

Dropping to S3 since we don't know of any actual web content affected by this, at this point (though it would be nice to fix!)

Comment 5

[Boris Chiou [:boris]]

Attachment: Bug 1739260 - Force to advance next band if we cannot get a suitable float available space.

This test case hangs because:

1. We get a flow area which is occupied by an element with float:right,
   so |AvailableSpaceShrunk()| doesn't work as we expected, and we hit an
   assertion in this function.
2. The size of |floatAvoidingBlock| keeps changing with different containing
   blocks (note: because of aspect-ratio and auto sizes), so we never hit the
   break condition if the new and old float available spaces are the same.
3. The above two reasons make |FloatAvoidingBlockFitsInAvailSpace()| always
   return true, because a 0x0 FloatAvoidingBlock always fits in any space.
   so we always stay in the same band (i.e. same |aBCoord|), and never go to
   the next band.

A possible way is to make sure we get a suitable available area for
|floatAvoidingBlock|, so the logic of positioning |floatAvoidingBlock|
works as we expected.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fb1114750895
Force to advance next band if we cannot get a suitable float available space. r=dholbert

Comment 7

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34131 for changes under testing/web-platform/tests

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/fb1114750895

Comment 9

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot