393517 - [FIX]Crash [@ nsFrameConstructorState::ProcessFrameInsertions] with float, XUL, block-in-inline

Status: RESOLVED FIXED

(Core :: Layout: Floats, defect, P1)

Description

[Jesse Ruderman]

Attachment: testcase

Loading the testcase (in a Mac trunk debug build) triggers a pair of assertions followed by a crash.

###!!! ASSERTION: Should have float containing block here!: 'parent', file /Users/jruderman/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 1585
(AdjustFloatParentPtrs)

###!!! ASSERTION: Child list without containing block?: 'containingBlock', file /Users/jruderman/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 1466
(nsFrameConstructorState::ProcessFrameInsertions)

Null dereference crash:
0  nsFrameConstructorState::ProcessFrameInsertions
1  nsFrameConstructorState::~nsFrameConstructorState
2  nsCSSFrameConstructor::AppendFrames
3  nsCSSFrameConstructor::ContentAppended
...

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is a regression from bug 390425.  Thing is, the floats need to come out of the block but there's no float container for the inline.  Fun times!

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 278157 [details] [diff] [review]
Proposed fix

+      // Walk up until we either get a float containing block that's not part
+      // of an {ib} split, since otherwise we might have to ship floats out of
+      // it too.

This doesn't quite parse ...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 278157 [details] [diff] [review]
Proposed fix

I'll do s/either// when I check in.  ;)

This is a crash regression fix.  Fix should be safe and not affect performance much in general.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 278157 [details] [diff] [review]
Proposed fix

a1.9=dbaron

Comment 6

[Boris Zbarsky [:bzbarsky]]

Fixed.  Test checked in.