"ASSERTION: aFrame not the result of GetPrimaryFrameFor()?" with floating :first-letter

RESOLVED FIXED

Status

()

RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: jruderman, Unassigned)

Tracking

(Blocks: 2 bugs, {assertion, regression, testcase})

Trunk
assertion, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
Created attachment 278180 [details]
testcase

###!!! ASSERTION: aFrame not the result of GetPrimaryFrameFor()?: 'aFrame == aFrame->GetFirstContinuation()', file /Users/jruderman/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10940

Comment 1

11 years ago
Regression from bug 390425.  The frame tree looks the same as before that
bug though, so it seems we have always had this problem...
Blocks: 390425
Keywords: regression
OS: Mac OS X → All
Hardware: PC → All

Comment 2

11 years ago
Created attachment 278262 [details]
Frame tree

Comment 3

11 years ago
Created attachment 278264 [details] [diff] [review]
WIP

The problem seems to be that nsCSSFrameConstructor::FindPrimaryFrameFor()
can't find the first text frame since it's wrapped in an out-of-flow.
I guess we could detect this special case, if this is the frame we want to
be the primary frame?
Yeah, we had this issue all along; I just added the assertion in that bug.

I think FindPrimaryFrameFor should walk through placeholders when recursing into kids.  That would fix both this case and out-of-flow generated content when we start to support it.
It looks like bug 403425 was basically about this, as was bug 403245.

Fixed by checkin for bug 405186 (implements what I suggest in comment 4).
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Depends on: 405186
Flags: in-testsuite?
Resolution: --- → FIXED
(Reporter)

Comment 6

11 years ago
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.