Closed Bug 1227525 Opened 9 years ago Closed 3 years ago

Assertion failure: "We gave button-contents frame unconstrained available height, so it should be complete", with table-cell, float, & vertical writing-mode

Categories

(Core :: Layout: Floats, defect)

defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox45 --- affected

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: assertion, testcase)

Attachments

(5 files)

Attached file testcase
The assertion was added in:
https://hg.mozilla.org/mozilla-central/rev/7164978f006d
Attached file stack
Assertion failure: (0 == ((contentsReflowStatus) & 0x1)) (We gave button-contents frame unconstrained available height, so it should be complete), at layout/forms/nsHTMLButtonControlFrame.cpp:331
Attached file testcase 2
(Slightly tweaked testcase, removing a few small unnecessary bits.)
Summary: Assertion failure: "We gave button-contents frame unconstrained available height, so it should be complete" → Assertion failure: "We gave button-contents frame unconstrained available height, so it should be complete", with table-cell, float, & vertical writing-mode
I'll bet this is related to bug 1227616 (on table-cells & vertical writing-modes), or bug 1077521 more generally.

Based on the testcases here, it seems likely that the table-cell has a tall child with a vertical writing-mode, which ends up fragmenting (incomplete), and the table-cell likely passes that incomplete reflow-status up to the button, which surprises the button because it provided unconstrained height. Or something like that.

For now, I suppose we should soften this assertion to be non-fatal, since I doubt we'll have a quick/easy fix here, and I don't want to block fuzzers by having them abort on this.
Flexbox has a similar fatal assertion, which this modified testcase (swapping in a flex container for the button) triggers.
Attachment #8691496 - Attachment description: band-aid → band-aid: use nonfatal assertions (so fuzzers can proceed)
Frames splitting when the parent doesn't expect them to is pretty bad; we shouldn't paper over it by weakening the assertions.
Comment on attachment 8691496 [details] [diff] [review]
band-aid: use nonfatal assertions (so fuzzers can proceed)

OK, canceling review then.
Attachment #8691496 - Flags: review?(jfkthame)
(In reply to Daniel Holbert [:dholbert] from comment #5)
> Created attachment 8691492 [details]
> testcase 3 (with flex container instead of button)
> 
> Flexbox has a similar fatal assertion, which this modified testcase
> (swapping in a flex container for the button) triggers.

I think bug 1145743 covers that one. Will they be fixed by the same patch?
Possibly, yes (if the patch ends up fixing things on the table/table-cell side of things, which I think it needs to).
All testcases here WFM on Linux.

Both test cases WFM on macOS 10.15 on the latest Firefox Release 85.0.2 (64-bit). Based on this and Comment 11, closing this as resolved:worksforme.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: