Closed
Bug 455063
Opened 16 years ago
Closed 16 years ago
###!!! ASSERTION: no initial containing block: 'mInitialContainingBlock
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b2
People
(Reporter: bzbarsky, Assigned: MatsPalmgren_bugz)
References
()
Details
(Keywords: assertion, regression, testcase)
Attachments
(3 files, 2 obsolete files)
116 bytes,
text/html
|
Details | |
138 bytes,
text/html
|
Details | |
5.26 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
We hit this assertion on the testcase in the URL field, with this stack: #0 nsCSSFrameConstructor::GetFloatContainingBlock (this=0x7f82c20, aFrame=0xe8150f4) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7719 #1 0x02e1c27e in nsCSSFrameConstructor::ConstructInline (this=0x7f82c20, aState=@0xbfffc678, aDisplay=0xe8128cc, aContent=0x7f92d20, aParentFrame=0xe8128f0, aStyleContext=0x17dcf80, aIsPositioned=0, aNewFrame=0xe812974) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:12430 #2 0x02e1a4a8 in nsCSSFrameConstructor::ConstructFrameByDisplayType (this=0x7f82c20, aState=@0xbfffc678, aDisplay=0xe8128cc, aContent=0x7f92d20, aNameSpaceID=3, aTag=0x1008cf4, aParentFrame=0xe8128f0, aStyleContext=0x17dcf80, aFrameItems=@0xbfffc4f0, aHasPseudoParent=0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:6548 #3 0x02e1b0ca in nsCSSFrameConstructor::ConstructFrameInternal (this=0x7f82c20, aState=@0xbfffc678, aContent=0x7f92d20, aParentFrame=0xe8128f0, aTag=0x1008cf4, aNameSpaceID=3, aStyleContext=0x17dcf80, aFrameItems=@0xbfffc4f0, aXBLBaseTag=0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7515 #4 0x02e1b547 in nsCSSFrameConstructor::ConstructFrame (this=0x7f82c20, aState=@0xbfffc678, aContent=0x7f92d20, aParentFrame=0xe8128f0, aFrameItems=@0xbfffc4f0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7336 #5 0x02e1c66d in nsCSSFrameConstructor::ProcessChildren (this=0x7f82c20, aState=@0xbfffc678, aContent=0x7f928c0, aFrame=0xe8128f0, aCanHaveGeneratedContent=1, aFrameItems=@0xbfffc4f0, aParentIsBlock=1) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:11200 #6 0x02e1ce68 in nsCSSFrameConstructor::ConstructBlock (this=0x7f82c20, aState=@0xbfffc678, aDisplay=0xe812808, aContent=0x7f928c0, aParentFrame=0x17dc98c, aContentParentFrame=0x17dc98c, aStyleContext=0x17dce80, aNewFrame=0xbfffc5e4, aFrameItems=@0xbfffc5bc, aAbsPosContainer=0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:12293 #7 0x02e24ad9 in nsCSSFrameConstructor::ConstructDocElementFrame (this=0x7f82c20, aState=@0xbfffc678, aDocElement=0x7f928c0, aParentFrame=0x17dc98c, aNewFrame=0xbfffc758) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:4240 #8 0x02e24ff9 in nsCSSFrameConstructor::ReconstructDocElementHierarchyInternal (this=0x7f82c20) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7623 #9 0x02e250b5 in nsCSSFrameConstructor::ReconstructDocElementHierarchy (this=0x7f82c20) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:7532 #10 0x02e25355 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x7f82c20, aContent=0x7f928c0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:11048 #11 0x02e256b5 in nsCSSFrameConstructor::ProcessRestyledFrames (this=0x7f82c20, aChangeList=@0xbfffc8e0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsCSSFrameConstructor.cpp:9781 #12 0x02e8b2e5 in PresShell::RecreateFramesFor (this=0x12e5600, aContent=0x7f928c0) at /Users/bzbarsky/mozilla/debug/mozilla/layout/base/nsPresShell.cpp:3415 We might not need all the XBL goop, but I'm not sure yet.
Flags: blocking1.9.1?
Reporter | ||
Comment 1•16 years ago
|
||
We probably just need to reset the member somewhere.
Assignee | ||
Updated•16 years ago
|
Assignee: roc → mats.palmgren
OS: Mac OS X → All
Hardware: PC → All
Assignee | ||
Comment 2•16 years ago
|
||
Assignee | ||
Comment 3•16 years ago
|
||
Assignee | ||
Comment 4•16 years ago
|
||
ConstructDocElementFrame() initializes 'mInitialContainingBlock' too late for the cases where 'processChildren' is false, i.e. in the ConstructTableFrame() and ConstructBlock() cases because these two process there own children. http://hg.mozilla.org/mozilla-central/annotate/4dfc88a342b2/layout/base/nsCSSFrameConstructor.cpp#l4168 The changed comment referred to a 'mInitialContainingBlock' at the end of the method which wasn't there - I assume it's the processing at the end in general (the 'mDocElementContainingBlock' bit).
Attachment #338414 -
Flags: superreview?(roc)
Attachment #338414 -
Flags: review?(roc)
+ if (!mInitialContainingBlock) { + // The frame we're constructing will be the initial containing block. + // Set mInitialContainingBlock before processing children. + mInitialContainingBlock = blockFrame; + } When the root element has columns, I think this is setting mInitialContainingBlock to the inner block, not the columnset frame. I think we need to use *aNewFrame here.
Also, in ConstructDocElementHierarchy, when we get around to setting mInitialContainingBlock, we should probably assert that if it's not null then it's already the value we're going to set it to.
Assignee | ||
Comment 7•16 years ago
|
||
Good points. I did the assertion more restrictive than you suggested, requiring it must be set to 'contentFrame' unless 'processChildren' is true where it must be set to null. I've added a third crashtest that covers the column case (it triggers the new assertion using my first patch).
Attachment #338411 -
Attachment is obsolete: true
Attachment #338414 -
Attachment is obsolete: true
Attachment #338990 -
Flags: superreview?(roc)
Attachment #338990 -
Flags: review?(roc)
Attachment #338414 -
Flags: superreview?(roc)
Attachment #338414 -
Flags: review?(roc)
Attachment #338990 -
Flags: superreview?(roc)
Attachment #338990 -
Flags: superreview+
Attachment #338990 -
Flags: review?(roc)
Attachment #338990 -
Flags: review+
Comment 8•16 years ago
|
||
Is this going to land soon? It would be very nice for those of us hacking on Thunderbird, as it seems to fix an assertion that's hit very very frequently, and makes it painful to run under the debugger with XPCOM_DEBUG_BREAK set to "trap".
Comment 9•16 years ago
|
||
(SeaMonkey has this too.)
Flags: blocking1.9.1? → wanted1.9.1+
Reporter | ||
Comment 10•16 years ago
|
||
Pushed changeset ad4d8bd0f99b to fix this.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Comment 11•16 years ago
|
||
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081009 SeaMonkey/2.0a2pre] (home, debug default) (W2Ksp4) I had no explicit steps, but I don't seem to get the assertion anymore :-) V.Fixed
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.1b2
You need to log in
before you can comment on or make changes to this bug.
Description
•