kmcclusk, karnaze, attinasi, and I just had a long talk about views and
frames, and I thought I'd post some notes from that conversation here.
(I'm struggling with bug 96228, most likely a regression from an
over-zealous foray while fixing bug 55068, which was what led to this
discussion.)
It turns out that the view hierarcy does not maintain internal
consistency, and relies on the frame system to keep the view tree
coherent. Specifically,
1. Moving a view does not reposition any native widgets that reside in
the view's hierarchy. The view system requires that each view in the
hierarchy be positioned in order to properly position a widget that
may be associated with a view.
2. Expanding the bounds of a child view is not sufficient to increase
the bounds of a containing parent. In other words, when ``growing''
a child view's boundaries, it may be necessary to grow the parent
view's boundaries as well.
So how do we avoid violating (1)? A container frame may need to
(re-)position its children during reflow, and typically knows the
position (if not the dimensions) of a child frame before flowing the
child. So, if a parent moves a child before flowing the child, the
parent must also synchronize the child's view with the frame. This
ensures that each view is visited only once during reflow, ``on the way
down''. (I broke this, see bug 99722.)
OTOH, if a child frame needs to be positioned _after_ reflow (``on the
way up''), we do need to walk the view tree to synchronize any widgets.
Ideally, this would be rare, but it turns out that it may not be (e.g.,
tables require two passes to position cells, the block code may need to
adjust all the frames in a linebox to account for a frame's impact on
line height).
So the question we debated was: do the current rules about view
placement (even though not consistently followed) make sense? Or should
we consider some other model, for example, one where the view system
would maintain internal consistency?
I think we decided to stay the course, under the assumption that we could:
1. Optimize the line placement behavior in the block frame by
detecting when the line is correctly placed to start with, and
therefore doesn't require any special view fixup.
2. Optimize table (and box?) two-pass reflow by add a bit to the reflow
state that indicates we're in first-pass reflow, and views need not
be placed.
3. Identify optimizations in block code where we need not reflow a
child frame; e.g., because we're simply sliding the frame (or line).
4. Add some debug-only code to the view system that will verify
the view hierarchy's internal consistency.
I'll file bugs on these tasks.
chris
