Except for the changes in:
layout/generic/nsIFrame.h (part)
layout/style/nsComputedDOMStyle.h (all)
layout/style/nsRuleNode.cpp (part)
layout/style/nsStyleContext.cpp (part)
layout/style/nsStyleContext.h (part)
(see patch 3b in the bug), this patch was written with the sed script:
s/\<GetStyle\(Font\|Color\|List\|Text\|Visibility\|Quotes\|UserInterface\|TableBorder\|SVG\|Background\|Position\|TextReset\|Display\|Content\|UIReset\|Table\|Margin\|Padding\|Border\|Outline\|XUL\|SVGReset\|Column\)\>/Style\1/g
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).
Compute the amount of text in the scope of an nsFontInflationData
object. This walks the text that's inside of the block formatting
context at which this object is rooted, excluding the text that's inside
any nested BFC. Using the amount of text, the font sizes of the text,
and the line threshold preference, we compute whether to enable font
size inflation within that block formatting context.
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.
