Closed
Bug 266971
Opened 20 years ago
Closed 19 years ago
{ib} splits almost screw up float containing blocks (BuildFloatList removal)
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: bzbarsky, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(2 files)
517 bytes,
text/html
|
Details | |
695 bytes,
patch
|
Details | Diff | Splinter Review |
Consider the following situation: <inline> Text <block /> More test <float /> <block /> Text </inline> When we construct frames we put the float in the float list of the nearest block ancestor of the inline.... Then we go through AdjustOutOfFlowPtrs and change the relevant parent pointers to point to the anonymous block that the {ib} split created. Finally, the BuildFloatList() for that anonymous block pulls the floats into the right framelist too. So the end result is OK, but it rather depends on BuildFloatList()... Perhaps AdjustOutOfFlowPtrs should simply remove the relevant floats from the frame constructor state? Or perhaps we want to change the way we do ib splits to create the anonymous block when we first hit a block kid and push it as the float containing block?
Comment 1•20 years ago
|
||
We're filing bugs on things that we _almost_ get wrong now? ;-)
Reporter | ||
Comment 2•20 years ago
|
||
Yes, because I want to move in the direction of removing BuildFloatList(), since it makes pageload O(N^2) in some cases. I've fixed a bunch of CSSFrameConstructor issues recently such that we're getting closer to being able to get rid of it, I think. Fixing this bug would be a step on the way there.
Summary: {ib} splits almost screw up float containing blocks → {ib} splits almost screw up float containing blocks (BuildFloatList removal)
Comment 3•19 years ago
|
||
Comment 4•19 years ago
|
||
This assert disappears with the patch for bug 307277, does that answer your question in 266971 comment 14? (I will check that in now...)
Comment 5•19 years ago
|
||
I was referring to Boris' question in bug 307277 comment 14. Sorry for the spam.
Reporter | ||
Comment 6•19 years ago
|
||
Yeah, it does. Most excellent.
Comment 7•19 years ago
|
||
It fixed the attached testcase in this bug, but I'm seeing the assertion with the testcase in bug 307277 though...
Comment 8•19 years ago
|
||
Nevermind, I must have looked in the wrong window or something because it seems like it's actually gone now... Oh well, maybe we should put in that assertion and see what falls out?
Reporter | ||
Comment 9•19 years ago
|
||
Whatever falls out should block bug 282173. ;)
Reporter | ||
Comment 10•19 years ago
|
||
Fixed by checkin for bug 307277
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
Assignee | ||
Updated•6 years ago
|
Component: Layout: Misc Code → Layout
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•