This commit ensures MathML boolean attributes (namely displaystyle,
mo@stretchy, mo@symmetric, mo@largeop, mo@movablelimits,
munder@accentunder, mover@accent, munderover@accent,
munderover@accentunder) are ASCII case-insensitive [1]. For
displaystyle that was handled in [2]. For mover/munder/munderover
attributes, this is covered by a test case from scriptlevel-001.html
checking both case-insensitivity and dynamic changes at the same time ;
the latter still seems broken, so these checks are moved into separate
test cases. For mo attributes, a new WPT test is added. Note that
mo@accent, mo@fence, mo@separator are not part of MathML Core (with the
two last without visual effect), we make them case-insensitive for
consistency but don't bother adding tests for them.
[1] https://w3c.github.io/mathml-core/#dfn-boolean used here:
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1574087
Differential Revision: https://phabricator.services.mozilla.com/D218944
After bug 1890531, mathml.centered_operator is disabled and
U+002D HYPHEN-MINUS in <mo> no longer renders as U+2212 MINUS SIGN.
This patches restore this behavior as the change was unintentional, even
though this is not specified in MathML Core.
Differential Revision: https://phabricator.services.mozilla.com/D219085
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
Gecko always adds .2em space above and below stretchy operators but this
is not part of MathML Core and is causing several WPT failures. The
MATH table does not have any parameter for that so it's likely some
tweak that was added in the early days of MathML that may no longer be
necessary. This patch tentatively removes this feature by placing it
under a disabled-by-default flag.
Tests adjustments:
- table-width-1.xhtml: adjusted to work around antialiasing issue with the
top/bottom of stretchy operators (in the past the extra space added was
preventing this issue). This does not affect the testing goal, which is about
the width.
- stretchy-largeop-with-default-font-2.html: Some tests are failing depending
on the OS config so mark them as such. In the past, the extra vertical space
added was hiding the issue.
Differential Revision: https://phabricator.services.mozilla.com/D207014
Gecko always adds .2em space above and below stretchy operators but this
is not part of MathML Core and is causing several WPT failures. The
MATH table does not have any parameter for that so it's likely some
tweak that was added in the early days of MathML that may no longer be
necessary. This patch tentatively removes this feature by placing it
under a disabled-by-default flag.
Differential Revision: https://phabricator.services.mozilla.com/D207014
Gecko always adds .2em space above and below stretchy operators but this
is not part of MathML Core and is causing several WPT failures. The
MATH table does not have any parameter for that so it's likely some
tweak that was added in the early days of MathML that may no longer be
necessary. This patch tentatively removes this feature by placing it
under a disabled-by-default flag.
Differential Revision: https://phabricator.services.mozilla.com/D207014
The MathML code adjust vertical position of basic binary operators with
the NS_MATHML_OPERATOR_CENTERED flag set (e.g. plus, equal or minus
signs) so that their centers align with the math axis. This behavior
is not defined in MathML Core and is not necessary in practice for math
fonts (which are already designed with the desired vertical alignments).
This patch tries and removes this by placing that legacy behavior
under a disabled-by-default runtime flag.
Intent-to-ship: https://groups.google.com/a/mozilla.org/g/dev-platform/c/nlA0t4J0gzo
Differential Revision: https://phabricator.services.mozilla.com/D207026
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
nsMathMLOperators::LookupOperators(s) methods are currently use in three
places:
(1) In nsMathMLmoFrame::ProcessTextData(), where we need to check the
flags for each form of the operator and take the bitwise-or of all
of them, ignoring lspace/rspace.
(2) In nsMathMLOperators::GetStretchyDirection::ProcessTextData(), where
we need to check the direction for each form of the operator (in any
order) and return the first found, ignoring lspace/rspace.
(3) In nsMathMLmoFrame::ProcessOperatorData, where need to check the
specified form, and try fallback forms in the order prefix, postfix,
infix. When an entry is found, the code also clears the form bits of
mFlags and bitwise-or the found flags.
This commit modifies nsMathMLOperators::LookupOperator to only check
one form at once and can be used to easily implement (1) and (2). This
removes the need for nsMathMLOperators::LookupOperators.
A new method nsMathMLOperators::LookupOperatorWithFallback is introduced
to preserve the fallback prefix/postfix/infix check that is needed for
(3). Undocumented bitwise logic is moved out of that method.
Differential Revision: https://phabricator.services.mozilla.com/D157705
nsMathMLOperators::LookupOperators(s) methods are currently use in three
places:
(1) In nsMathMLmoFrame::ProcessTextData(), where we need to check the
flags for each form of the operator and take the bitwise-or of all
of them, ignoring lspace/rspace.
(2) In nsMathMLOperators::GetStretchyDirection::ProcessTextData(), where
we need to check the direction for each form of the operator (in any
order) and return the first found, ignoring lspace/rspace.
(3) In nsMathMLmoFrame::ProcessOperatorData, where need to check the
specified form, and try fallback forms in the order prefix, postfix,
infix. When an entry is found, the code also clears the form bits of
mFlags and bitwise-or the found flags.
This commit modifies nsMathMLOperators::LookupOperator to only check
one form at once and can be used to easily implement (1) and (2). This
removes the need for nsMathMLOperators::LookupOperators.
A new method nsMathMLOperators::LookupOperatorWithFallback is introduced
to preserve the fallback prefix/postfix/infix check that is needed for
(3). Undocumented bitwise logic is moved out of that method.
Differential Revision: https://phabricator.services.mozilla.com/D157705
"integral" is an internal operator property that Gecko uses when
selecting larger variants for integrals, for fonts that don't provide
a good value for DisplayOperatorMinHeight. The code points of operators
having the integral property are located in two contiguous blocks, so
this commit replaces existing implementation with a direct check. There
is no behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D157316
- Remove unused boolean return value from
nsMathMLOperators::LookupOperator.
- Move NS_ASSERTION to validate parameters at the top of
nsMathMLOperators::LookupOperator.
- The operator form is an integer corresponding to the last two bits of
nsOperatorFlags, so represent it as uint8_t when passed as a
parameter of nsMathMLOperators::LookupOperator, as well as in the
single caller nsMathMLmoFrame::ProcessTextData and in GetOperatorData
in order to avoid confusion.
This removes the use of NS_MATHML_OPERATOR_GET_FORM for casting.
Note that the function already has an NS_ASSERTION to check the
validity of the parameter.
- Use modern for loop syntax to try the infix, postfix and prefix
forms in nsMathMLOperators::LookupOperator/LookupOperators instead of
duplicating code for each GetOperatorData call. Also make more
explicit the subtle use of lazy evaluation to skip one
GetOperatorData call from nsMathMLOperators::LookupOperator.
Differential Revision: https://phabricator.services.mozilla.com/D157196
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
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
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
We do not expose it nor ever style it. Just use the parent style all the
time. This avoids problematic style resolution calls during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D84358
This commit renames nsMathMLElement/nsMathMLElementFactory classes into
MathMLElement/MathMLElementFactory and moves the former into the mozilla::dom
namespace. This is a preliminary step to introduce MathML DOM (bug 1579602).
Code behavior is not changed.
Differential Revision: https://phabricator.services.mozilla.com/D45128
Additionally, this patch makes `nsFrame.h` stop including `nsIPresShell.h`
and makes each users include `mozilla/PresShell.h` instead. So, this improves
rebuild performance of `nsIPresShell.h` (and `mozilla/PresShell.h` in the
future).
Note that due to `nsIFrame::PresShell()`, `mozilla::` prefix is necessary for
`PresShell` in a lot of classes which are derived from `nsIFrame` even in
`.cpp` files.
Differential Revision: https://phabricator.services.mozilla.com/D27476
Frédéric Wang