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
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
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
Frédéric Wang