Currently, when a size variant is used for large variants of stretchy
operators, we modify the bounding box of the glyph by substracting any
specified italic correction from the calculated width. This is to mimic
legacy behavior of old math fonts that were handling subscript of
slanted integrals by specifying a width smaller than the actual glyph
extent.
This causes rendering issues when one draws the background of the
corresponding `<mo>` element, or when a slanted integral is rendered in
right-to-left mode. This bug is also detected by WPT test
mathml/presentation-markup/scripts/subsup-parameters-2.html since
one case assumes subscript is placed at the right of the base minus
the italic correction. We strengthen it a bit by actually checking the
base's width is properly set.
MathML Core describes italic correction of all MathML boxes (
measurement of how slanted they are), how it can be calculated
recursively from the box's children and how it applies to sub/sup
script positioning. In this patch, we implement a simplified version
addressing above issues and covering simple cases currently supported
by browsers and actually useful in practice.
Differential Revision: https://phabricator.services.mozilla.com/D277987
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
From [1]:
> Place the mmultiscripts base and <mprescripts> boxes at inline offsets
inline-offset and with their alphabetic baselines aligned with the
alphabetic baseline.
Also tweak subsup-6.html to compute bounding box of the <mprescripts>
element at the time a test is run. Otherwise reflow due to resize of the
`<div id="log">` element can make the test fail.
[1] https://w3c.github.io/mathml-core/#base-with-prescripts-and-postscripts
Differential Revision: https://phabricator.services.mozilla.com/D222614
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
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
This commit removes the preference
mathml.error_message_layout_for_invalid_markup.disabled that controls
whether we layout invalid markup with the special "invalid-markup"
message. It has been set to true since Firefox 106. For now, this
"invalid-markup" layout is still used for the legacy implementation
of the <maction> element and will be removed in bug 1788223.
Differential Revision: https://phabricator.services.mozilla.com/D184691
This commit removes the preference
mathml.error_message_layout_for_invalid_markup.disabled that controls
whether we layout invalid markup with the special "invalid-markup"
message. It has been set to true since Firefox 106. For now, this
"invalid-markup" layout is still used for the legacy implementation
of the <maction> element and will be removed in bug 1788223.
Differential Revision: https://phabricator.services.mozilla.com/D184691
This commit removes the preference
mathml.error_message_layout_for_invalid_markup.disabled that controls
whether we layout invalid markup with the special "invalid-markup"
message. It has been set to true since Firefox 106. For now, this
"invalid-markup" layout is still used for the legacy implementation
of the <maction> element and will be removed in bug 1788223.
Differential Revision: https://phabricator.services.mozilla.com/D184691
- Remove script_shift_attributes preference and related test, warning
message and parsing.
- Do not remove subscriptshift/supscripshift atoms, since they are
still needed for nsTreeSanitizer.
Differential Revision: https://phabricator.services.mozilla.com/D154195
gfxFontCache acquires and releases its mutex during various operations.
In order to keep the state internally consistent, we should only release
the lock after the full operation is complete. This involves moving the
deletion of gfxFont to outside the lock via a temporary discard array.
The expiration state should not be protected by the gfxFont's mutex
since we don't hold it during most operations. Instead we should hold
gfxFontCache's mutex because then we can guarantee the operation is
atomic, particularly when a worker wants a font, and the main thread is
aging the generations.
When a font is returned from gfxFontCache, we now return it already
removed from the tracker, and with its refcount updated. This avoids any
potential races between the expiration timer and a worker accessing the
font, as well as simplying the callers so they don't need to be aware of
addref-ing manually in case the result is to be discarded (so that it
gets readded to the tracker).
Differential Revision: https://phabricator.services.mozilla.com/D151821
gfxFontCache acquires and releases its mutex during various operations.
In order to keep the state internally consistent, we should only release
the lock after the full operation is complete. This involves moving the
deletion of gfxFont to outside the lock via a temporary discard array.
The expiration state should not be protected by the gfxFont's mutex
since we don't hold it during most operations. Instead we should hold
gfxFontCache's mutex because then we can guarantee the operation is
atomic, particularly when a worker wants a font, and the main thread is
aging the generations.
When a font is returned from gfxFontCache, we now return it already
removed from the tracker, and with its refcount updated. This avoids any
potential races between the expiration timer and a worker accessing the
font, as well as simplying the callers so they don't need to be aware of
addref-ing manually in case the result is to be discarded (so that it
gets readded to the tracker).
Differential Revision: https://phabricator.services.mozilla.com/D151821
Build errors fixed here:
layout/mathml/nsMathMLmpaddedFrame.h:68:14: error: field has incomplete type 'nsCSSValue'
* Fixed by including this type's header.
[various files]: error: use of undeclared identifier 'nsLayoutUtils'
* Fixed by including the nsLayoutUtils header.
[various files]: error: member access into incomplete type 'mozilla::dom::Element'
* These are for calls to [something]->AsElement()->HasAttr() and SetAttr(). Fixed by including Element.h in all affected .cpp files.
[various files]: error: member access into incomplete type 'nsINode::Document' (aka 'mozilla::dom::Document')
* These are for calls to mContent->OwnerDoc()->WarnOnceAbout(). Fixed by including Document.h in all affected files.
Depends on D138202
Differential Revision: https://phabricator.services.mozilla.com/D138203
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
Frédéric Wang Nélar