The first of these pieces of information is the intrinsic widths cached
on a block.
The second of them is the font inflation cached on a text frame (which
might be set to 1.0 at this point if a text frame has previously had
intrinsic width calculation done on it, but hasn't been reflowed).
The first of these pieces of information is the intrinsic widths cached
on a block.
The second of them is the font inflation cached on a text frame (which
might be set to 1.0 at this point if a text frame has previously had
intrinsic width calculation done on it, but hasn't been reflowed).
This structure is per block formatting context because we have to make a
single inflation decision for things like consecutive runs of paragraphs
of text. Inflating some paragraphs and not others (within the same
sequence of adjacent paragraphs) based on the amount of text in each one
would be disastrous. Otherwise it's ideal for the units to be as small
as possible as long as they merge such sequences; therefore this uses a
definition corresponding to CSS's idea of elements that establish new
block formatting contexts.
This is the third of three patches to rework the way we handle getting
the font inflation container and width data during reflow, which are
needed so that we can sometimes honor inflation during intrinsic width
calculation (which we need to do to make some form controls inflate
correctly).
Add an extra change hint, UpdateOverflow, that can be used to specify that
a frame's overflow areas may have changed and that they need to be recalculated.
When a transform on a frame changes, instead of marking it for reflow, set this
hint instead.
There is an added virtual function on nsIFrame, UpdateOverflow, which is called
recursively on a frame when the corresponding hint is set, to allow it to
update its overflow areas.
This does not address users of font metrics in layout/mathml/ (for text
size and alignment issues) or in layout/xul (for text size and sizing of
listbox and tree widgets): see all the callers of GetFontMetricsFor*
in those directories.
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).
