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

RESOLVED FIXED in mozilla1.9alpha8

Status

()

Core
Layout: Floats
P1
critical
RESOLVED FIXED
10 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: bz)

Tracking

(Blocks: 2 bugs, 4 keywords)

Trunk
mozilla1.9alpha8
assertion, crash, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Created attachment 278016 [details]
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
...
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!
Assignee: nobody → bzbarsky
Blocks: 390425
Keywords: regression
OS: Mac OS X → All
Priority: -- → P1
Hardware: PC → All
Summary: Crash [@ nsFrameConstructorState::ProcessFrameInsertions] with float, XUL, block-in-inline → [FIX]Crash [@ nsFrameConstructorState::ProcessFrameInsertions] with float, XUL, block-in-inline
Target Milestone: --- → mozilla1.9 M8
Created attachment 278157 [details] [diff] [review]
Proposed fix
Attachment #278157 - Flags: superreview?(roc)
Attachment #278157 - Flags: review?(roc)
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 ...
Attachment #278157 - Flags: superreview?(roc)
Attachment #278157 - Flags: superreview+
Attachment #278157 - Flags: review?(roc)
Attachment #278157 - Flags: review+
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.
Attachment #278157 - Flags: approval1.9?
Comment on attachment 278157 [details] [diff] [review]
Proposed fix

a1.9=dbaron
Attachment #278157 - Flags: approval1.9? → approval1.9+
Fixed.  Test checked in.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Crash Signature: [@ nsFrameConstructorState::ProcessFrameInsertions]
You need to log in before you can comment on or make changes to this bug.