For math/mtd, we still include lspace/rspace when we adjust the size of
children in `AddInterFrameSpacingToSize` until bug 2018403 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D284282
For math/mtd, we still include lspace/rspace when we adjust the size of
children in `AddInterFrameSpacingToSize` until bug 2018403 is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D284282
nsMathMLContainerFrame (and its derived classes) relies on a
FinishReflow() method that is called at the end of Reflow(). So just
clear the NS_MATHML_STRETCH_DONE bit there instead of DidReflow().
Differential Revision: https://phabricator.services.mozilla.com/D226118
Preliminary patch to removing the return value of Place, as it is always
NS_OK. The logic associated with it being false has also been removed,
along with DidReflowChildren, which was only called in these paths.
Differential Revision: https://phabricator.services.mozilla.com/D265801
`MutationEvent_Bindings::MODIFICATION`,
`MutationEvent_Bindings::ADDITION` and `MutationEvent_Bindings::REMOVAL`
will be removed. Therefore, we need alternative `enum class` for that.
This patch makes `nsIFrame` and subclasses use the new one.
Differential Revision: https://phabricator.services.mozilla.com/D263053
This patch implements support for the width/height properties on
MathML elements [1]. The general algorithm from the spec is as
follows:
(1) The outcome of the math layout is a "math content box".
(2) The content box sets its size from computed width/height values. If
auto, it's the one of the "math content box". This patch ignores
percentage values for now [2] [3].
(3) math content box is shifted so that its inline-start and top edges
aligns with the ones of the content box. There are exceptions
elements like mfrac and munder/mover/munderover which instead
horizontally center the math content box within the content box.
For baseline adjustment, we follow what Chromium does, see [4].
(4) Padding+border are added around the content box. Note that we
ignore the box-sizing property for now [5].
The patch essentially tweaks the various MathML layout algorithms to
perform steps (3) and (4) before the calls to
GetBorderPaddingForPlace and InflateReflowAndBoundingMetrics.
[1] https://w3c.github.io/mathml-core/#layout-algorithms
[2] https://github.com/w3c/mathml-core/issues/76
[3] https://github.com/w3c/mathml-core/issues/77
[4] https://github.com/w3c/mathml-core/issues/259
[5] https://github.com/w3c/mathml-core/issues/257
Below is more information about test coverage:
- width-height-001: Verify that width, height, inline-size and block-size
properties sets the size of the content box. This test used to verify
they are ignored, this patch fixes the `<meta name="assert">` tag.
It also adds a test for the case the specified size is smaller than the
content (we force non empty descendants to make sure this content is
large enough) and to verify the width is used for the preferred width.
- width-height-002, width-height-003: These are reftests visually checking
offsets of the math content box within a larger content box (specified
by width/height) for the mtext, mrow, mpadded, mfrac, msqrt, mroot,
in LTR/RTL modes. In particular they allow to verify some painted
elements like fraction bar and radical symbols.
- width-height-004: This test more directly checks that the math content
box is horizontally centered within a larger content box for munder,
mover, munderover and mfrac. This patch extends the test to cover the
case when the math content box is wider (i.e. overflowing outside the
content box) and removes unnecessary specified height.
- width-height-005: New test for other layout algorithm that don't
center the math content box, checking inline-start edges of children
when a width is specified. We check both LTR/RTL modes and
wider/narrower content boxes.
- width-height-006: Same but checking the top edges for larger/smaller
height and verifying that baseline is perserved.
Differential Revision: https://phabricator.services.mozilla.com/D221436
Currently, nsMathMLContainerFrame::AttributeChanged always force a
reflow. This patch removes that behavior tweaks the following derived
classes:
- menclose: Don't mark intrinsic size of descendants dirty, since the
notation is added around the children, only affecting the element's
metrics.
- mfrac: Don't mark intrinsic size dirty for the linethickness
attribute, since it only affects vertical metrics.
- mo: Rebuild 'automatic' data and relayout the entire embellished
operator hierarchy for all operator properties. I haven't checked the
details of the MathML 'automatic' data, so it may be a bit too
aggressive. But at least a reflow is necessary.
- mspace/mpadded: Only mark intrinsic size dirty for the element and
ancestors, and only for attributes affecting vertical metrics. Also
remove `InvalidateFrame()` call since we don't have any display item.
- mtable: Don't force reflow or data rebuild when displaystyle changes.
This was probably needed before displaystyle was re-implemented as
an attribute mapped to the math-style CSS property.
There is at least one dynamic test for each of the MathML
attributes affecting layout and they don't regress after this patch:
https://bugzilla.mozilla.org/show_bug.cgi?id=1918308#c0
Differential Revision: https://phabricator.services.mozilla.com/D221925
This method is now only used at one place (more precisely, inside the
nsMathMLContainerFrame::GetIntrinsicISizeMetrics() method) and only
calls the Place() method with the IntrinsicSize + MeasureOnly flags.
This patch removes it and instead ensure we call Place() directly from
GetIntrinsicISizeMetrics(). There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221630
This method is now only used at one place (more precisely, inside the
nsMathMLContainerFrame::GetIntrinsicISizeMetrics() method) and only
calls the Place() method with the IntrinsicSize + MeasureOnly flags.
This patch removes it and instead ensure we call Place() directly from
GetIntrinsicISizeMetrics(). There is no behavior changes.
Differential Revision: https://phabricator.services.mozilla.com/D221630
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
This patch changes the signature to `GetMinISize()`, `GetPrefISize()`,
`IntrinsicISize` by adding a helper struct as a preparation. Then we can just
add more data such as a percentage basis to the struct without altering the
signature in the future.
When passing `IntrinsicSizeInput` struct down to another helper method, we
generally just pass the original one if the method is computing the intrinsic
size of our own or our anonymous children. If the method is computing our
children's intrinsic contribution, we'll need to create a brand new
`IntrinsicSizeInput` for our children.
Differential Revision: https://phabricator.services.mozilla.com/D219521
MathML classes has a few Place*() methods used for layout and intrinsic
size calculation. These methods have a parameter "aPlaceOrigin"
indicating whether the children and other painted objects should have
their final positions set, or if the method is only called for measuring.
This parameter is typically set to false when doing intrinsic size
calculation or when performing some non-final measurement for operator
stretching.
For intrinsic size calculation, it is generally enough to perform
placement with aPlaceOrigin=false and ignoring the vertical metrics.
Some Place*() methods also have a parameter "aWidthOnly" for special
handling. For example, msqrt stretches a radical symbol vertically to
match the height of the content but when doing intrinsic size
calculation this is approximated to nsMathMLChar::GetMaxWidth() instead.
When we implement border/padding/margin we should also be able to
choose between using IntrinsicISizeOffsets() or GetUsed*() methods.
Finally, some Place*() methods initially call a place routing of a
parent class before further tweaking the layout. For example, msqrt
uses mrow layout on children and adds some radical symbol on top of
them. When we implement border/padding, we should make sure we don't
add the border/padding before the final result.
In order to handle all these placement behaviors, a new EnumSet is
introduced. This commit does not change behavior. Handling of padding,
border and margin will be handled in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D216669
MathML classes has a few Place*() methods used for layout and intrinsic
size calculation. These methods have a parameter "aPlaceOrigin"
indicating whether the children and other painted objects should have
their final positions set, or if the method is only called for measuring.
This parameter is typically set to false when doing intrinsic size
calculation or when performing some non-final measurement for operator
stretching.
For intrinsic size calculation, it is generally enough to perform
placement with aPlaceOrigin=false and ignoring the vertical metrics.
Some Place*() methods also have a parameter "aWidthOnly" for special
handling. For example, msqrt stretches a radical symbol vertically to
match the height of the content but when doing intrinsic size
calculation this is approximated to nsMathMLChar::GetMaxWidth() instead.
When we implement border/padding/margin we should also be able to
choose between using IntrinsicISizeOffsets() or GetUsed*() methods.
Finally, some Place*() methods initially call a place routing of a
parent class before further tweaking the layout. For example, msqrt
uses mrow layout on children and adds some radical symbol on top of
them. When we implement border/padding, we should make sure we don't
add the border/padding before the final result.
In order to handle all these placement behaviors, a new EnumSet is
introduced. This commit does not change behavior. Handling of padding,
border and margin will be handled in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D216669
MathML classes has a few Place*() methods used for layout and intrinsic
size calculation. These methods have a parameter "aPlaceOrigin"
indicating whether the children and other painted objects should have
their final positions set, or if the method is only called for measuring.
This parameter is typically set to false when doing intrinsic size
calculation or when performing some non-final measurement for operator
stretching.
For intrinsic size calculation, it is generally enough to perform
placement with aPlaceOrigin=false and ignoring the vertical metrics.
Some Place*() methods also have a parameter "aWidthOnly" for special
handling. For example, msqrt stretches a radical symbol vertically to
match the height of the content but when doing intrinsic size
calculation this is approximated to nsMathMLChar::GetMaxWidth() instead.
When we implement border/padding/margin we should also be able to
choose between using IntrinsicISizeOffsets() or GetUsed*() methods.
Finally, some Place*() methods initially call a place routing of a
parent class before further tweaking the layout. For example, msqrt
uses mrow layout on children and adds some radical symbol on top of
them. When we implement border/padding, we should make sure we don't
add the border/padding before the final result.
In order to handle all these placement behaviors, a new EnumSet is
introduced. This commit does not change behavior. Handling of padding,
border and margin will be handled in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D216669
Most frame types have identical or very similar implementation for GetMinISize()
and GetPrefISize(), and many of them already have `IntrinsicISize()` to unify
the implementation. This patch introduces nsIFrame::IntrinsicISize() so that
derived classes only need to override one method.
`nsBlockFrame`, `ColumnSetWrapperFrame`, and `nsColumnSetFrame` are the only
three classes where their `GetMinISize()` and `GetPrefISize()` have significant
differences. Therefore, we rename `GetMinISize()` and `GetPrefISize()` to
`MinISize()` and `PrefISize`, respectively, and use them as helpers to implement
their `IntrinsicISize()`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D217790
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
The following classes deriving from nsBlockFrame always set
NS_BLOCK_STATIC_BFC in their constructors or initializers:
- nsComboboxControlFrame
- nsFileControlFrame
- nsSelectsAreaFrame
- ColumnSetWrapperFrame
- nsMathMLmathBlockFrame
Do that in nsBlockFrame::Init instead. Behavior is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D199097
After D198523, NS_BLOCK_FLOAT_MGR and NS_BLOCK_MARGIN_ROOT are always
set simultaneously when initiating a frame, so we can merge them into a
single NS_BLOCK_STATIC_BFC flag. The freed bit is used to define a new
NS_BLOCK_DYNAMIC_BFC flag that has the same effect and is now used for
frames with paint/layout containment so that in D197043 they can be
updated later without having to reconstruct the frame tree. Finally
NS_BLOCK_BFC_STATE_BITS is the bitwise union of these BFC flags.
The following changes are made and cause no behavior changes:
- Instead of testing whether NS_BLOCK_FLOAT_MGR or NS_BLOCK_MARGIN_ROOT
is set, or whether all of the bits from
NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS are set, we test whether any
of the NS_BLOCK_BFC_STATE_BITS is set.
- Instead of adding NS_BLOCK_FORMATTING_CONTEXT_STATE_BITS when
constructing a frame, we add NS_BLOCK_STATIC_BFC. The exception is
for frame with paint/layout containment, for which we set
NS_BLOCK_DYNAMIC_BFC instead.
Differential Revision: https://phabricator.services.mozilla.com/D198530
Extend the per-frame-class bit we have to devirtualize IsLeaf to also
devirtualize IsFrameOfType. That is, move this data to FrameClasses.py.
This was done by going through all the frame classes, trying to preserve
behavior.
The only quirky thing is that I had to add two more trivial frame
classes, `nsAudioFrame` for audio elements, and
`nsFloatingFirstLetterFrame`. That's because these frame classes were
returning different answers at runtime, but they do this only on
conditions that trigger frame reconstruction (floating, and being an
audio element, respectively).
Differential Revision: https://phabricator.services.mozilla.com/D194703
Frédéric Wang Nélar