Up till now layout code assumed that the (top, left) of a view's 
bounds is equal to the (top, left) of the frame which owns the view. 
This assumption had to be broken to fix bug 13213, to handle cases 
where the frame has child frames that extend above or to the left of 
the parent.

It used to be that nsIView::GetPosition() always returned the top left 
corner of the rectangle returned by nsIView::GetBounds(). As of now, 
nsIView::GetPosition() returns the (top, left) of the view's frame's 
origin, relative to the view's parent view. OTOH, nsIView::GetBounds() 
returns the area actually covered by the view. The (top, left) of this 
  rectangle is usually the same as returned by GetPosition(), but 
sometimes child frames push the (top, left) of the bounds above or to 
the left of GetPosition(), and in some cases the (top, left) of the 
bounds can even be below and to the right of GetPosition() (typically 
when the view's frame is actually size 0 but it has nonempty, 
nonclipped child frames).

What this means is that you should use GetPosition() if you want to 
translate coordinates from one view to another. On other other hand, 
if you want to find out the area actually covered by a view, use 
GetBounds().

If reflow sets the aCombinedArea for a frame to extend above or to the 
left of the frame's bounds, then in 
nsContainerFrame::SyncFrameViewAfterReflow() the frame's view will be 
extended to cover the aCombinedArea. This will allow you to reliably 
paint outside the frame's bounds if you need to.

See bug 13213 for more details and an example.

Rob


Reply via email to