When one of the two factors governing the effective container width for font
inflation changes, we need to mark all affected frames as dirty.
While the visible area commonly changes because of viewport changes and we can
catch those through the check for ISize resizes of the top-level frame
("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation
of the effective container width into the FontInflationData itself, especially
since the effective container width calculation in nsLayoutUtils is the only
consumer of the NCAISize currently stored by the FontInflationData.
That way
- we can be sure that really all changes of the visible width will correctly
mark all affected frames as dirty
- can avoid repeatedly recalculating the effective container width
- can also detect the cases where the effective container width actually remains
the same after a change in one of its input factors and skip forcing a full
dirty reflow for all descendants just because of font inflation.
While the code in nsLayoutUtils was technically always using the writing
mode (horizontal/vertical) of each individual frame for determining which
dimension of the visible size should be used for clamping, just using the
writing mode of the respective flow root should be enough, since each change in
the writing mode should create a new flow root.
This assumption should already hold today because
1. as per the Writing Modes CSS spec, a change in writing mode compared to its
parent means that the affected block cannot be purely "inline", but at most
"inline-block".
2. Generally, any non-inline frame will be marked as a font inflation container.
3. Any block frame whose writing direction doesn't match its parent will be a
block formatting context, which implies NS_BLOCK_FLOAT_MGR.
4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation
container will also become a font inflation flow root.
but because this chain of reasoning is not the most direct, we also add a
corresponding assertion to better catch any potential bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D5578
--HG--
extra : moz-landing-system : lando
When one of the two factors governing the effective container width for font
inflation changes, we need to mark all affected frames as dirty.
While the visible area commonly changes because of viewport changes and we can
catch those through the check for ISize resizes of the top-level frame
("!mFrame->GetParent() && isIResize"), it still seems nicer to move calculation
of the effective container width into the FontInflationData itself, especially
since the effective container width calculation in nsLayoutUtils is the only
consumer of the NCAISize currently stored by the FontInflationData.
That way
- we can be sure that really all changes of the visible width will correctly
mark all affected frames as dirty
- can avoid repeatedly recalculating the effective container width
- can also detect the cases where the effective container width actually remains
the same after a change in one of its input factors and skip forcing a full
dirty reflow for all descendants just because of font inflation.
While the code in nsLayoutUtils was technically always using the writing
direction of each individual frame for determining which dimension of the
visible size should be used for clamping, just using the writing direction of
the respective flow root should be enough, since each change in writing
direction should create a new flow root.
This assumption should already hold today because
1. as per the Writing Modes CSS spec, a change in writing mode compared to its
parent means that the affected block cannot be purely "inline", but at most
"inline-block".
2. Generally, any non-inline frame will be marked as a font inflation container.
3. Any block frame whose writing direction doesn't match its parent will be a
block formatting context, which implies NS_BLOCK_FLOAT_MGR.
4. Any block frame that has both NS_BLOCK_FLOAT_MGR set and is a font inflation
container will also become a font inflation flow root.
but because this chain of reasoning is not the most direct, we also add a
corresponding assertion to better catch any potential bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D5578
--HG--
extra : moz-landing-system : lando
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
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.
Sylvestre Ledru
Jan Henning
Bogdan Tara
Daniel Holbert
Ting-Yu Lin
Jonathan Kew
Ehsan Akhgari
Mats Palmgren
Ehsan Akhgari
L. David Baron
Ryan VanderMeulen
Phil Ringnalda
Ed Morley
Gervase Markham