Closed Bug 451117 Opened 15 years ago Closed 14 years ago

"ASSERTION: Reframes of this letter frame will mess with the root of a native anonymous content subtree!"

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: jruderman, Assigned: roc)

References

Details

(4 keywords)

Attachments

(3 files)

Loading content/base/crashtests/395469-1.xhtml triggers:

###!!! ASSERTION: Reframes of this letter frame will mess with the root of a native anonymous content subtree!: '!letterContent->IsRootOfNativeAnonymousSubtree()', file /Users/jruderman/central/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11570

This is a regression from within the last few days.
Flags: in-testsuite+
Mmm.  I bet we're giving the letter frame the newly-added content node for the :before element.  That's the right thing to be doing as far as the first-letter frame goes.

I guess we could test whether this is OK by toggling the display or float or something on that first-letter to trigger an attempted frame reconstruct and seeing whether things blow up.  I suspect at the moment they do.

Perhaps we should make RecreateFramesForContent handle this case or something and then remove this assert?
Blocks: 238072
Flags: blocking1.9.1?
Yeah, I think we'll have to walk up.
OS: Mac OS X → All
Assignee: nobody → roc
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P3
Attached file stack
Here is the stack for the assertion.
Attachment #346992 - Attachment mime type: application/octet-stream → text/plain
roc has a stack somewhere to make RecreateFramesForContent deal, as I recall.
er, I meant a patch, not a stack
The patch for bug 460012 doesn't fix this.
Er, it doesn't fix the assert, but of course that's not the point. Let me look...
Attached file testcase #1
This testcase doesn't blow up, on trunk. It does cause
###!!! ASSERTION: FirstLetterStyle set on line with floating first letter: '!(outOfFlowFrame->GetType() == nsGkAtoms::letterFrame && GetFirstLetterStyleOK())', file /Users/roc/mozilla-checkin/layout/generic/nsLineLayout.cpp, line 902
I think because nsBlockFrame still thinks it has a first-letter in-flow child so calls SetFirstLetterStyleOK. Or something like that. But this assertion seems to be harmless.
With the patch for bug 460012, testcase #1 doesn't raise any assertions. So I think it's safe to say that the patch fixes this bug.
Depends on: 460012
Whiteboard: [depends on 460012]
Fixed by 460012
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Hardware: PC → All
Whiteboard: [depends on 460012] → [Fixed by bug 460012]
Target Milestone: --- → mozilla1.9.1b3
Roc, sorry when I have to reopen this bug but opening the crashtest from comment 0 still show this assertion with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081202 Minefield/3.2a1pre

###!!! ASSERTION: Reframes of this letter frame will mess with the root of a native anonymous content subtree!: '!letterContent->IsRootOfNativeAnonymousSubtree()', file /mozilla/src/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11860
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [Fixed by bug 460012]
Target Milestone: mozilla1.9.1b3 → ---
Attached patch remove assertionSplinter Review
This assertion is no longer needed, since we fixed the underlying problem in bug 460012.
Attachment #351500 - Flags: superreview?(bzbarsky)
Attachment #351500 - Flags: review?(bzbarsky)
Whiteboard: [needs review]
Attachment #351500 - Flags: superreview?(bzbarsky)
Attachment #351500 - Flags: superreview+
Attachment #351500 - Flags: review?(bzbarsky)
Attachment #351500 - Flags: review+
Whiteboard: [needs review] → [needs landing]
Pushed 0e0c23ff64cf
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing] → [needs 191 landing]
(removing erroneous fixed1.9.1 marking - sorry)
Keywords: fixed1.9.1
Pushed 84c5e8702af9 to 1.9.1
Keywords: fixed1.9.1
Whiteboard: [needs 191 landing]
Target Milestone: --- → mozilla1.9.1b3
The assertion isn't shown anymore when opening the crashtest from comment 0.

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081221 Minefield/3.2a1pre ID:20081221222459
Status: RESOLVED → VERIFIED
Target Milestone: mozilla1.9.1b3 → mozilla1.9.2a1
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
David, this patch has been landed on mozilla-central after we branched for 1.9.1. The TM of any of such bugs we have already set to 1.9.2a1 while the fixed/verified keyword shows that it is fixed for Fx3.1. So why we should have 3.1b3 here?
Verified on 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090403 Shiretoko/3.5b4pre ID:20090403220515
Target Milestone: mozilla1.9.1b3 → mozilla1.9.2a1
You need to log in before you can comment on or make changes to this bug.