After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
After moving FrameChildListID into mozilla namespace, `kPrincipalList` etc. are
also exposed in the mozilla namespace. In the next part, I'll convert
FrameChildListID enum into an enum class, so the naming pollution shouldn't be
an issue.
This patch has a nice side effect that it is now easier to remove all the
aliases of FrameChildListID (`kPrincipalList` etc.) defined in multiple places
since it is confusion to have the same thing written in different ways, e.g.
`nsIFrame::kPrincipalList`, `mozilla::layout::kPrincipalList`,
`FrameChildListID::kPrincipalList`, `kPrincipalList`.
This patch doesn't change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D161863
This commit moves crash tests from dom/mathml and layout/mathml into
testing/web-platform/tests/mathml/crashtests/mozilla, trying to do only
minimal changes (i.e. use 'test-wait' instead of 'reftest-wait' and
fix whitespace errors). lint errors are ignored for usage of
setTimeout as well as the invalid XML file testing bug 289180.
Regarding 400157.xhtml, it uses special powers to trigger a
zoom changes. It could probably be tweaked to convert to a mochitest or
rely on a different dynamic change. However, this was testing a crash for
the `<mfenced>` element in nsMathMLmfencedFrame whose code has been
completely removed, so it's now hard to reproduce the original crash.
Also that makes the test no longer very useful, so we just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D159491
This commit moves crash tests from dom/mathml and layout/mathml into
testing/web-platform/tests/mathml/crashtests/mozilla, trying to do only
minimal changes (i.e. use 'test-wait' instead of 'reftest-wait').
The exception is 400157.xhtml which uses special powers to trigger a
zoom changes. It could probably be tweaked to convert to a mochitest or
rely on a different dynamic change. However, this was testing a crash for
the `<mfenced>` element in nsMathMLmfencedFrame whose code has been
completely removed, so it's now hard to reproduce the original crash.
Also that makes the test no longer very useful, so we just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D159491
This commit introduces a MathML preference for the legacy implementation
of the lquote/rquote attributes, and disable it by default. This feature
is not implemented in Chromium or WebKit, not part of MathML Core and
Firefox's implementation has issues (e.g. bugs 787215 and 1108608).
Differential Revision: https://phabricator.services.mozilla.com/D158479
This commit ensures that the following operators use category I from
MathML Core's operator dictionary [1] [2]:
U+1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL
U+1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL
which corresponds to zero lspace/rspace and stretchy. There should
already be exhaustive WPT tests operator-dictionary-* to check
these and other properties, but they may be shadowed by existing
failures or Firefox bugs, so add some more specific reftests for
spacing and stretching. However, nsMathMLmoFrame and nsMathMLChar
don't handle non-BMP characters very well, so only the first one
currently passes.
Also tweak updateOperatorDictionary.pl to ignore these special
operators.
[1] https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator
[2] https://w3c.github.io/mathml-core/#operator-dictionary-categories-values
Differential Revision: https://phabricator.services.mozilla.com/D157788
MathML Core specifies that operators containing a UTF-16 strings of
length 2 ending with U+0338 COMBINING LONG SOLIDUS OVERLAY or U+20D2
COMBINING LONG VERTICAL LINE OVERLAY should just use the properties of
the first character. This commit implements that behavior. It removes
obsolete entries that are superseded by this rule and modifies
updateOperatorDictionary.pl to ensure that no such entries are present.
Existing WPT test operator-dictionary-combining.html is already passing
after bug 1789583 because the operators tested use the default spacing.
So extend it to try operators with different spacing.
[1] https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator
Differential Revision: https://phabricator.services.mozilla.com/D157707
MathML Core specifies that operators containing a UTF-16 strings whose
length is not 1 or 2 should use the default properties [1]. This
commit removes the obsolete strings of length 3 from our operator
dictionary and tweak updateOperatorDictionary.pl to ensure it only
accepts strings of 1 or 2 characters. This also adds an early return
in LookupOperator to immediately fallback to default properties.
[1] https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator
Differential Revision: https://phabricator.services.mozilla.com/D157706
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
MathML Core specifies that operators containing a UTF-16 strings of
length 2 ending with U+0338 COMBINING LONG SOLIDUS OVERLAY or U+20D2
COMBINING LONG VERTICAL LINE OVERLAY should just use the properties of
the first character. This commit implements that behavior. It removes
obsolete entries that are superseded by this rule and modifies
updateOperatorDictionary.pl to ensure that no such entries are present.
Existing WPT test operator-dictionary-combining.html is already passing
after bug 1789583 because the operators tested use the default spacing.
So extend it to try operators with different spacing.
[1] https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator
Differential Revision: https://phabricator.services.mozilla.com/D157707
MathML Core specifies that operators containing a UTF-16 strings whose
length is not 1 or 2 should use the default properties [1]. This
commit removes the obsolete strings of length 3 from our operator
dictionary and tweak updateOperatorDictionary.pl to ensure it only
accepts strings of 1 or 2 characters. This also adds an early return
in LookupOperator to immediately fallback to default properties.
[1] https://w3c.github.io/mathml-core/#dfn-algorithm-to-determine-the-category-of-an-operator
Differential Revision: https://phabricator.services.mozilla.com/D157706
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
While looking at moving the flag around I realized that the only reason
we have FontMetricsProvider and co is because we didn't have access to
the per-document font-prefs cache. That's trivial to fix tho, so do
that and simplify the setup for font queries even more.
Differential Revision: https://phabricator.services.mozilla.com/D157589
This is not used at all in our code and are not present in MathML Core's
dictionary. Let's remove them from the Perl script that manage update
of the dictionary.
Differential Revision: https://phabricator.services.mozilla.com/D157318
"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
The font-size math keyword is implemented. It behaves as a font-size: 1em
with the extra fixup due to math-level change (and other legacy MathML
attributes). After that change, the CSS for math-level / font-size: math
is behaving as per the specification, so the math-depth is turned in
nightly.
The adjusting function for font-size: math is modified so that it's
executed only if both font-size: math (otherwise the spec says no scale
should apply) and math-depth (otherwise the scale is 1 and function exists
early anyway) are set on the element. Also checking if the current node
has a scriptsizemultiplier rule applied to use MathML3's scaling is
incorrect. Instead this is changed to check if a non-default
scriptsizemultiplier is set.
Differential Revision: https://phabricator.services.mozilla.com/D91744
Currently, our internal operator dictionary contains a "mirrorable"
property which is used to render stretched or large operators
(such as fences or integrals) in RTL mode, by applying a scale transform.
This is done via the nsMathMLChar class, which is only used for
operators that have a "largeop" or "direction" property in the operator
dictionary [1] [2]. Additionally, this "mirrorable" property was added
with the help of a Perl script, relying on "mirrored" property from
Unicode [3].
This commit removes this property from our internal operator dictionary
and switches to direct retrieval of the Unicode property via
mozilla::intl::UnicodeProperties::IsMirrored. There are four "mirrorable"
characters from our dictionary that are not in [1] (namely
LEFT/RIGHT SINGLE/DOUBLE QUOTATION MARK) but because they don't have
"largeop" or "direction" properties, they don't use nsMathMLChar
anyway. Similarly, they are new characters that are "mirrored" in
Unicode but were not "mirrorable" (LESS-THAN SIGN, LEFT-POINTING DOUBLE
ANGLE QUOTATION MARK, ...) but they won't use nsMathMLChar either.
So there should be no behavior change.
[1] https://searchfox.org/mozilla-central/rev/9769b513e38ee4f5df9d5d1eff55ff7cdc8cbf81/layout/mathml/nsMathMLmoFrame.cpp#58
[2] https://searchfox.org/mozilla-central/rev/9769b513e38ee4f5df9d5d1eff55ff7cdc8cbf81/layout/mathml/nsMathMLmoFrame.cpp#165
[3] https://www.compart.com/en/unicode/mirrored
Differential Revision: https://phabricator.services.mozilla.com/D157303
- 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
This is a first step towards aligning our dictionary with MathML Core.
non-BMP Arabic characters are not integrated yet and obsolete entries
are preserved. Here is the details of how the update was
semi-automatically performed:
1. Changed the URL of `unicode.xml` that is used by WPT and MathML Core.
Also tweaked the `./updateOperatorDictionary.pl` to handle the fact
that the accent property is no longer part of the MathML Core
dictionary, so that we still preserve our internal values for now.
2. Called `./updateOperatorDictionary.pl download` to fetch `unicode.xml`
and generate `dictionary.xml`.
3. Called `./updateOperatorDictionary.pl compare` to generate
`differences.txt` and `new_dictionary.txt`. The following summary is
provided by the script:
- 197 obsolete entries (22 of them are related to stretching)
- 682 unchanged entries
- 247 conflicting entries (90 of them are related to stretching)
- 248 new entries (120 of them are related to stretching)
4. Copied `new_dictionary.txt` into `mathfonts.properties`, keeping
the obsolete entries at the end and removing the
U+1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL
and U+1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL
(non-BMP entries don't seem to be handled well by the Perl script).
5. Ran `./updateOperatorDictionary.pl compare` again:
- 197 obsolete entries (22 of them are related to stretching)
- 1173 unchanged entries
- 2 conflicting entries (0 of them are related to stretching)
- 2 new entries (1 of them are related to stretching)
The 2 new entries are the non-BMP Arabic characters mentioned
above. The 2 remaining conflicting entries are U+2215 DIVISION
SLASH and U+221A SQUARE ROOT which lose their "mirrorable" property
during conversion via the stylesheet `operatorDictionary.xsl` because
they don't have any other operator properties. Let's keep them as
"mirrorable", this notion is not part of the current version of MathML
Core anyway.
6. Ran `./updateOperatorDictionary.pl check` and got errors
"operator has a stretchy form, but all forms have not the same
direction" for operators U+2295, U+2296, U+2297, U+2299. Add
missing `direction:vertical` to them. After running again, no
errors are found.
7. Ran WPT tests and found new assertion failure in largeop code saying
that "Stretching should be in the vertical direction" in
operator-dictionary-largeop-004.html (for U+2A1D) and
operator-dictionary-largeop-006.html (for U+2A1E). Also removed
expectation for new passing tests.
8. Adjusted the script to check that largeop operator have
direction:vertical and fixed the new errors found by the script
Verified the WPT largeop tests pass again.
9. Fix another bug that caused the mirrorable property to be duplicated
in the output (this does not change parsing behavior in
nsMathMLOperators.cpp though).
10. Ran `./updateOperatorDictionary.pl clean` to remove temporay files.
Differential Revision: https://phabricator.services.mozilla.com/D156654
This is a first step towards aligning our dictionary with MathML Core.
non-BMP Arabic characters are not integrated yet and obsolete entries
are preserved. Here is the details of how the update was
semi-automatically performed:
1. Changed the URL of `unicode.xml` that is used by WPT and MathML Core.
Also tweaked the `./updateOperatorDictionary.pl` to handle the fact
that the accent property is no longer part of the MathML Core
dictionary, so that we still preserve our internal values for now.
2. Called `./updateOperatorDictionary.pl download` to fetch `unicode.xml`
and generate `dictionary.xml`.
3. Called `./updateOperatorDictionary.pl compare` to generate
`differences.txt` and `new_dictionary.txt`. The following summary is
provided by the script:
- 197 obsolete entries (22 of them are related to stretching)
- 682 unchanged entries
- 247 conflicting entries (90 of them are related to stretching)
- 248 new entries (120 of them are related to stretching)
4. Copied `new_dictionary.txt` into `mathfonts.properties`, keeping
the obsolete entries at the end and removing the
U+1EEF0 ARABIC MATHEMATICAL OPERATOR MEEM WITH HAH WITH TATWEEL
and U+1EEF1 ARABIC MATHEMATICAL OPERATOR HAH WITH DAL
(non-BMP entries don't seem to be handled well by the Perl script).
5. Ran `./updateOperatorDictionary.pl compare` again:
- 197 obsolete entries (22 of them are related to stretching)
- 1173 unchanged entries
- 2 conflicting entries (0 of them are related to stretching)
- 2 new entries (1 of them are related to stretching)
The 2 new entries are the non-BMP Arabic characters mentioned
above. The 2 remaining conflicting entries are U+2215 DIVISION
SLASH and U+221A SQUARE ROOT which lose their "mirrorable" property
during conversion via the stylesheet `operatorDictionary.xsl` because
they don't have any other operator properties. Let's keep them as
"mirrorable", this notion is not part of the current version of MathML
Core anyway.
6. Ran `./updateOperatorDictionary.pl check` and got errors
"operator has a stretchy form, but all forms have not the same
direction" for operators U+2295, U+2296, U+2297, U+2299. Add
missing `direction:vertical` to them. After running again, no
errors are found.
7. Ran WPT tests and found new assertion failure in largeop code saying
that "Stretching should be in the vertical direction" in
operator-dictionary-largeop-004.html (for U+2A1D) and
operator-dictionary-largeop-006.html (for U+2A1E). Also removed
expectation for new passing tests.
8. Adjusted the script to check that largeop operator have
direction:vertical and fixed the new errors found by the script
Verified the WPT largeop tests pass again.
9. Fix another bug that caused the mirrorable property to be duplicated
in the output (this does not change parsing behavior in
nsMathMLOperators.cpp though).
10. Ran `./updateOperatorDictionary.pl clean` to remove temporay files.
Differential Revision: https://phabricator.services.mozilla.com/D156654
This is testing the legacy <maction> element, a feature currently
disabled by default and intended to be removed in the future. The test
tries to enable it, but that does not always work. So let's disable the
test for now, it will be removed in the future.
Differential Revision: https://phabricator.services.mozilla.com/D156528
Andi-Bogdan Postelnicu
Frederic Wang
Norisz Fay
Stanca Serban
Martin Robinson
Ting-Yu Lin
Noemi Erli
sskcvqikf
Marian-Vasile Laza
Cristian Tuns
Butkovits Atila
Emilio Cobos Álvarez
criss