Closed Bug 393661 Opened 17 years ago Closed 17 years ago

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

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: assertion, regression, testcase)

Attachments

(3 files)

Attached file testcase
###!!! ASSERTION: aFrame not the result of GetPrimaryFrameFor()?: 'aFrame == aFrame->GetFirstContinuation()', file /Users/jruderman/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 10940
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
Attached file Frame tree
Attached patch WIPSplinter Review
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
Closed: 17 years ago
Depends on: 405186
Flags: in-testsuite?
Resolution: --- → FIXED
Crashtest checked in.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: