Outer table frames act as CSS2.1 table wrapper boxes. We used to lay them out
without taking their margins into the account, which meant that their width was
always equal to the available width. This breaks horizontal positioning of
absolutely positioned kids of a table frame.
The main purpose of this patch is to apply the margins of tables to their outer
frame, instead of the inner frame. This means that the inner table frame will
always have a zero margin, which means that a lot of the stuff which used to
rely on the fact that table margins are applied to the inner frame need to
change.
In particular, in order to get the computed margins of a table, we used to query
the inner table frame, and this patch corrects that. Also, when shrink wrapping
tables, we used to not take the margins of the inner table frame into account,
which is fixed by this patch too. nsBlockReflowState::
ComputeReplacedBlockOffsetsForFloats also needed to be changed to read the
margin values from the outer frame too.
Also, as part of this patch, we start to respect the CSS2.1 margin model for
captions on all sides. This means that in particular, the top/bottom margins on
the top-outside and bottom-outside captions will not be collapsed with the
top/bottom margins of the table, and that the margins of the caption element
contribute to the width and height of the outer table frame. The
427129-table-caption reftest has been modified to match this new behavior.
Another side effect of this bug is fixing bug 87277, and the reftests for that
bug are marked as passing in this patch.
Implement GetChildList(ChildListID) and GetChildLists(nsTArray<ChildList>*)
for various frame classes. Remove GetAdditionalChildListName(PRInt32)
methods and associated macros and list index constants.
Since this affects only the *visual* overflow and not the *scrollable*
overflow, this patch should result in no behavior changes, since the
necessary visual overflow is added in
nsTextFrame::UnionAdditionalOverflow (since the text frame now draws the
shadows of text decorations, just like it draws text decorations
themselves).
There was nothing wrong with SetFontFromStyle, except that it's just one
more API to think about (and one more API to audit and modify for font
inflation work to happen in bug 627842).
When we do multiple reflow passes inside a container with page or column
breaks, we might hit this assertion for legitimate reasons. In
particular, if a reflow places the first-in-flow of a float in a later
continuation of its containing block than it was in before, or if a
reflow reflows a float that was split and then pushes the line
containing the float's placeholder, then during reflow we push the
continuations of the float back through the continuations of the
containing block, and in intermediate states of this process (such as
when this assertion fires), we have two continuations of the same float
within the same parent.
