We should do this, so that we can simplify block and inline reflow. Implementation notes so far: 1) Anonymous blocks created to wrap inlines should probably ignore their text-indent, unless they're the first such block in their parent. Add a test for this. 2) Floats should probably be parented to the anonymous blocks. This means we want to do the analysis on frame construction item lists, not on frame lists; reparenting floats is a pain. 3) Need to think about dynamic insertions.
[Notes from this morning] This will create two subclasses of nsBlockFrame, tentatively called nsBlockContextFrame - block of blocks nsInlineContextFrame - block of inlines Plan so far is to do the {ib} analysis on frame items, then have special code to optimize common mutations such as appends. For appending a block to a list of inlines, the optimization would 1. mutate the containing nsInlineContextFrame into an anonymous block 2. insert a new primary nsBlockContextFrame as its parent 3. append the block to the new primary frame's child list. This avoids reparenting the inlines. Cases where we escape into reconstructing frames: - out of flows - scrollframes - multicol We can optimize some of these later if needed. The root element, and SVG foreign object will be nsBlockContextFrames. XULdesc, table cells, and buttons need analysis to know which is appropriate as usually nsInlineContextFrame will be appropriate. Not sure about XulBoxContainingNonBoxes. Plan: 1. Add nsIFrame->ReplaceFrame implementation 2. Create nsBlockContextFrame and nsInlineContextFrame via hg copy as subclasses of nsBlockFrame 3. Frame construction (bzbarsky) a. rewrite {ib} to analyze FCItems b. do whitespace analysis on FCItems c. construct nsBlockContextFrame or nsInlineContextFrame as appropriate 4. Splitting nsBlockFrame (fantasai) a. Remove unused code from the new frame classes b. Remove nsLineBox from nsBlockContextFrame
> Plan: > 1. Add nsIFrame->ReplaceFrame implementation > 2. Create nsBlockContextFrame and nsInlineContextFrame via hg copy as > subclasses of nsBlockFrame If they're subclasses, why do you need hg copy? > 4. Splitting nsBlockFrame (fantasai) > a. Remove unused code from the new frame classes > b. Remove nsLineBox from nsBlockContextFrame A possible alternative that I might prefer is: 2. add trivial subclasses to nsBlockFrame.h/cpp 4. do an hg copy to new files and split the code appropriately
The plan I understood was exactly what comment 2 says, yes (trivial subclasses added initially, hg copy when doing the split).
*** Bug 846040 has been marked as a duplicate of this bug. ***
or
