"ASSERTION: frame must have content (unless at the top of the tree)" with floating first-letter, range operations

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
x86
Mac OS X
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Created attachment 388289 [details]
testcase

###!!! ASSERTION: SetMayHaveFrame failed?: 'mContent->MayHaveFrame()', file /Users/jruderman/central/layout/generic/nsFrame.cpp, line 369

###!!! ASSERTION: frame must have content (unless at the top of the tree): 'aFrame->GetContent() || !aParentContent || !aParentContent->GetParent()', file /Users/jruderman/central/layout/base/nsFrameManager.cpp, line 1096

Also, the 'F' remains on the screen, and I think it shouldn't.

Related to bug 483346?  (See bug 483346 comment 2.)
> ###!!! ASSERTION: SetMayHaveFrame failed?: 'mContent->MayHaveFrame()', file
> /Users/jruderman/central/layout/generic/nsFrame.cpp, line 369

This means mContent is a text node with a null parent.

> ###!!! ASSERTION: frame must have content (unless at the top of the tree):

This would be a first-letter frame with a null mContent.  Not sure how it got there.
Ah, it happens because we init the first-letter frame with letterContent, which is gotten like so:

  nsIContent* letterContent = aTextContent->GetParent();

So the real issue is that aTextContent isn't actually in the tree anymore...
The patch in bug 457514 fixes this.
Depends on: 457514
(Reporter)

Comment 4

9 years ago
Yep, seems fixed.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 5

9 years ago
tn added this as a crashtest:
http://hg.mozilla.org/mozilla-central/rev/790386742994
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.