82296 - Knowledge of continuation frames (NextInFlow/PrevInFlow) should be encapsulated in the frame classes

Status: NEW

(Core :: Layout, defect)

Description

[Marc Attinasi]

Spun off of bug 79508, this bug is a reminder to look at the FrameManager's use 
of the NextInFlow in ComputeStyleChangeFor. Rather than ReResolving style on the 
NextInFlow, it might be preferable to encapsulate the handling of the 
NextInFlow to the primary frame. 

The concern is that we are spreading knowledge about the internal workings of 
the frames too widely. To that end, it may be preferable to hide the NextInFlow 
notion from the frame's public interface altogether (eg. make GetNext|PrevInFlow 
and SetNext|PrevInFlow protected on nsIFrame). CSSFrameConstructor has lots of 
code that 'knows' about NextInFlow semantics, and the FrameManager and PresShell 
have tiny bits of knowledge too. Clearly, this needs more analysis, just don't 
want to forget about it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't really see this as being important enough to work on.