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
--HG--
rename : dom/mathml/nsMathMLElement.cpp => dom/mathml/MathMLElement.cpp
rename : dom/mathml/nsMathMLElement.h => dom/mathml/MathMLElement.h
rename : dom/mathml/nsMathMLElementFactory.cpp => dom/mathml/MathMLElementFactory.cpp
extra : moz-landing-system : lando
See https://groups.google.com/forum/#!topic/mozilla.dev.platform/70NFnet82cU
This commit introduces a new mathml.xlink.disabled option to disable support
for XLink attributes on MathML elements together with a use counter and
deprecation warning when support is enabled. For now, support is only disabled
in Nighly.
In the past, we relied on custom MathML deprecation warnings but those are
removed here. Corresponding tests for these legacy warning messages are
also removed from test_bug553917.html.
link-1.xhtml is run with XLink support enabled (since it check xlink:href)
while browser_contentAltClick.js is updated to check whether XLink has any
effect on MathML, depending on whether the option is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D43332
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/5#issuecomment-475506856
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/kl5c87mBlO0
This patch introduces a new preference
mathml.deprecated_style_attributes.disabled in order to disable legacy support
for attributes background, color, fontfamily, fontsize, fontstyle and
fontweight. Note that xlink:href will be handled separately in bug 1575870.
* A new counter and deprecation message is introduced for these attributes.
In nsMathMLElement, the old WarnDeprecated calls are replaced with a single
call to WarnOnceAbout for the deprecate attributes. Notice that for some
reason, the color attribute used to send warning in both ParseAttribute and
MapMathMLAttributesInto.
* sMtableStyles is removed and replaced with a simple comparison.
* sMathML3Attributes is split into two tables: one for script attributes which
will be handled in bug 1548471 and one for style attributes, handled here.
The attributes in this second table is now ignored when the feature flag is
disabled.
* test_bug553917.html is updated so that it no longer checks the old warning
messages for these attributes. New warning messages have been verified
manually.
* Reftests checking support for these attributes are run with the support
enabled.
* Finally, WPT tests are run with the support disabled and a new test
is added to verify that these attributes are no longer mapped to CSS.
Differential Revision: https://phabricator.services.mozilla.com/D43111
--HG--
extra : moz-landing-system : lando
This commit introduces new counters and deprecation warnings for the following
MathML features:
* mathspace names (bug 1575542)
* mathsize names (bug 1548527)
* linethickness names (bug 1548529)
Note: helper parsing functions for mfrac and mpadded are changed to non-static
in order to pass the document parameter needed to log warnings to the console.
Change manually tested with
<math>
<mspace width="thinmathspace"></mspace>
<mpadded width="2thickmathspace"></mpadded>
<mfrac linethickness="thin"><mn>1</mn><mn>2</mn></mfrac>
<mtext mathsize="big">3</mtext>
</math>
Differential Revision: https://phabricator.services.mozilla.com/D42890
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/23
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/wIjm9JjVHNg
This commit introduces a new preference option
mathml.legacy_number_syntax.disabled to disable legacy MathML numbers
(e.g. "1234.") that are not supported by CSS. This feature is now disabled by
default.
* test_bug553917.html is updated to check that such legacy values now cause an
error message to be logged into the console when the feature is disabled.
* Legacy MathML features are now disabled for WPT mathml test in a global
__dir__.ini file. Removing legacy numbers allow to pass
mathml/relations/css-styling/lengths-2.html
Differential Revision: https://phabricator.services.mozilla.com/D42907
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/75
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/yEMdIOo4i-0
This commit introduces a new preference option
mathml.mathspace_names.disabled to disable *mathspace names for MathML lengths.
For now, these are only disabled in Nightly builds.
* test_bug553917.html is updated to check that these values now cause an
error message to be logged into the console when mathsize names are used
and the feature disabled.
* mathml-negativespace-ref.html and positive-namedspace.html verify support for
mathspace names, so force running them with the support enabled.
* The reference files for mo-lspace-rspace-2.html, mo-lspace-rspace-3.html,
mo-lspace-rspace.html, op-dict-8.html and op-dict-9.html use explicit
lspace/rspace attributes corresponding to the one read from the operator
dictionary. Instead of running them with mathspace names enabled, use the
equivalent em values from core
https://mathml-refresh.github.io/mathml-core/#operator-dictionary
See https://github.com/mathml-refresh/mathml/issues/75#issuecomment-523016332
* Force WPT tests
mathml/presentation-markup/fractions/frac-linethickness-002.html and
mathml/relations/css-styling/lengths-2.html to be run with the features
disabled and remove corresponding failure expectation.
Differential Revision: https://phabricator.services.mozilla.com/D42643
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/24
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/-yV6wb3klSA
This commit introduces a new preference option
mathml.nonzero_unitless_lengths.disabled to disable MathML nonzero unitless
values like "5" for 500%. MathML nonzero unitless are now disabled by default
but it could be easily enabled again later if we decide otherwise.
* test_bug553917.html is updated to check that these values now cause an error
message to be logged into the console rather than a deprecated warning
when nonzero unitless lengths are disabled.
Additionally, the test checking invalid double dots "2..0" is updated not
to use unitless syntax.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mfrac-linethickness-2.xhtml and number-size-1.xhtml check support for
unitless lengths so they are now run with that support enabled.
* WPT tests frac-linethickness-001.html and lengths-1.html are executed with
the some MathML features disabled in order to make them pass.
We get more assertion passing for the "Legacy numbers" test of
lengths-2.html ; however there are still some issues to address
(see bug 1574751).
Differential Revision: https://phabricator.services.mozilla.com/D42427
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/7
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/kyB34PjYXek
This commit introduces a new preference option
mathml.mathsize_names.disabled to disable mathsize keyword values. For
now, these are only disabled in Nightly builds.
* test_bug553917.html is updated to check that these values now cause an
error message to be logged into the console when mathsize names are used
and the feature disabled.
* The old test 355548-3.xml checks support for mathsize names and also uses
several features that are going to be deprecated. So it is just run with
the proper preference adjustment.
* mathml/relations/css-styling/mathsize-attribute-legacy-values.html passes
after this change so the test is run with the mathsize names disabled too
and the failure expectation is removed.
* mathml/relations/css-styling/mathsize-attribute-css-keywords.html is added
to check that CSS keywords won't be supported when we switch to using the
CSS parser in the future. This test passes now when the "small" keyword
is not accepted so it is run with the mathsize names disabled too.
Differential Revision: https://phabricator.services.mozilla.com/D42426
--HG--
extra : moz-landing-system : lando
Update test_bug553917 so that it does not expect invalid lengths
for "thin", "thick", "medium" when mfrac linethickness names are
allowed. This fixes failure in non-nightly builds where these
names are not disabled yet.
Differential Revision: https://phabricator.services.mozilla.com/D42455
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/4
and https://groups.google.com/forum/#!topic/mozilla.dev.platform/G91-vBeC3Rw
This commit introduces a new preference option
mathml.mfrac_linethickness_names.disabled to disable linethickness names. For
now, these names are only disabled in Nightly builds. Announcements and actual
disabling of this and other MathML features will be considered later.
* test_bug553917.html is updated to check that these values now cause an error
message to be logged into the console.
* mstyle-1.xhtml is updated to use a numeric linethickness since the point of
the test is just to check that the attribute is not supported on mstyle, not
about the actual attribute value.
* Other fractions tests relying on linethickness names are executed with the
proper preference adjustment.
* mathml/presentation-markup/fractions/frac-linethickness-001.html is now
closer to its expectation ; however the test still fails because nonzero
unitless values are not removed yet. See
https://github.com/mathml-refresh/mathml/issues/24
Differential Revision: https://phabricator.services.mozilla.com/D42323
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/22
* mathml/relations/css-styling/attribute-mapping-001.html (length, dir)
* mathml/relations/html5-tree/display-1.html (display)
* mathml/relations/css-styling/displaystyle-1.html (displaystyle)
* mathml/relations/css-styling/displaystyle-2.html (displaystyle)
* mathml/relations/css-styling/mathvariant-case-sensitivity.html (mathvariant)
layout/reftests/bugs/355548-3.xml has been updated now that units are case
insensitive.
Note:
* mathml/relations/css-styling/attribute-mapping-002.html also checks
case insensitiveness of mathvariant and displaystyle but for now we map
these attributes to internal -moz-* CSS properties.
* mathcolor and mathbackground values are already case insensitive, this
is verified by mathml/relations/css-styling/attribute-mapping-001.html
Differential Revision: https://phabricator.services.mozilla.com/D42081
--HG--
extra : moz-landing-system : lando
See https://github.com/mathml-refresh/mathml/issues/22
* mathml/relations/css-styling/attribute-mapping-001.html (length, dir)
* mathml/relations/html5-tree/display-1.html (display)
* mathml/relations/css-styling/displaystyle-1.html (displaystyle)
* mathml/relations/css-styling/displaystyle-2.html (displaystyle)
* mathml/relations/css-styling/mathvariant-case-sensitivity.html (mathvariant)
Note:
* mathml/relations/css-styling/attribute-mapping-002.html also checks
case insensitiveness of mathvariant and displaystyle but for now we map
these attributes to internal -moz-* CSS properties.
* mathcolor and mathbackground values are already case insensitive, this
is verified by mathml/relations/css-styling/attribute-mapping-001.html
Differential Revision: https://phabricator.services.mozilla.com/D42081
--HG--
extra : moz-landing-system : lando
These are duplicate and out-of-date version of the following web platform tests:
testing/web-platform/tests/mathml/presentation-markup/fractions/frac-parameters-1.html
testing/web-platform/tests/mathml/presentation-markup/fractions/frac-parameters-2.html
testing/web-platform/tests/mathml/relations/css-styling/lengths-2.html
Differential Revision: https://phabricator.services.mozilla.com/D41778
--HG--
extra : moz-landing-system : lando
* All but the last parameter of test_opentype-limits.html are verified by
mathml/presentation-markup/scripts/underover-parameters-1.html
* test_opentype-fraction.html is equivalent to
mathml/presentation-markup/fractions/frac-parameters-1.html
(however, fraction-1.otf is used by other tests).
* mathml/tests/test_opentype-radical.html is equivalent to
mathml/presentation-markup/radicals/root-parameters-1.html
* test_opentype-scripts.html is equivalent to
mathml/presentation-markup/scripts/subsup-parameters-1.html
* mathml/tests/test_opentype-stack.html is equivalent to
mathml/presentation-markup/fractions/frac-parameters-2.html
Differential Revision: https://phabricator.services.mozilla.com/D41783
--HG--
extra : moz-landing-system : lando
It seems better to convert this before adding a new flag (in bug
1547759) and risking replacing the wrong 0 with a flag.
Differential Revision: https://phabricator.services.mozilla.com/D40562
--HG--
extra : moz-landing-system : lando
It was made pointless by the previous patch.
This replaces callers that had a frame type for another reason with the
frame type check that IsTableCell did, and callers that needed to call
Type() with an IsTableCellFrame call.
Differential Revision: https://phabricator.services.mozilla.com/D40561
--HG--
extra : moz-landing-system : lando
This distinguishes better between the overloaded aspect of the PerFrameKey and the
actual mixed value.
Differential Revision: https://phabricator.services.mozilla.com/D37804
--HG--
extra : moz-landing-system : lando
This static method is assumed to have the same signature as the type's constructor,
and so we must have an implementation of ComputePerFrameKey for each constructor
a display item provides that is called by MakeDisplayItem. Notably this excludes
the MakeClone constructor for a lot of items.
There is a default varargs implementation on nsDisplayItem which everyone
inherits by default, so types which previously didn't overload this method
still don't need to.
Providing an implementation of ComputePerFrameKey on some display item type
shadows the varargs implementation, so one doesn't need to worry about overloading
one constructor but forgetting about another -- if you do, the compiler will only
see the overload and complain that the signature doesn't match.
One slightly annoying result of this is that display items which previously
inherited an overloaded implementation from a superclass now must provide
their own manual implementations. Although as far as I could tell, all of
those cases had a trivial implementation of key=0 (the super class supported
custom keys but the subclasses didn't make use of it).
In those cases I just hardcoded key=0, but it's possible that it would be
better to call into the superclass' implementation to be more robust to changes.
Differential Revision: https://phabricator.services.mozilla.com/D37803
--HG--
extra : moz-landing-system : lando
For now, always pass null, except when passing it through from one
overload to another.
Differential Revision: https://phabricator.services.mozilla.com/D38389
--HG--
extra : moz-landing-system : lando
This should be an idempotent patch. The way to come up with this patch has been:
* Run the first script attached to the bug and pipe it to xclip, then paste it
in color.rs
* Add the relevant #[derive] annotations and remove the color.mako.rs
definition.
* Reorder the values to match the ColorID definition, on which some widget
prefs and caching stuff relies on.
* Manually port some documentation from nsLookAndFeel.h
* Run `rg 'eColorID_' | cut -d : -f 1 | sort | uniq >files`
* Run the second script attached to the bug.
* Manually fix usage of `LAST_COLOR` (adding the `End` variant), and adding
casts to integer as needed.
* Add an static assert so that people remember to update the prefs, rather than
a comment on the definition :)
Differential Revision: https://phabricator.services.mozilla.com/D32610
--HG--
extra : moz-landing-system : lando
D29542 fixed the bogus checks that was making nested pseudo-elements match
author rules. This adds tests and ends up being just a cleanup, though as it
turns out we it also fixes an issue with ::slotted() matched from
Element.matches.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
This helps for the next patch, since some of the table backgrounds items want to compute this without position:relative taken into account.
Differential Revision: https://phabricator.services.mozilla.com/D29279
--HG--
extra : moz-landing-system : lando
Move ApplyOpacity(), CanApplyOpacity(), Paint() and PaintWithClip() methods to nsPaintedDisplayItem
Differential Revision: https://phabricator.services.mozilla.com/D30225
--HG--
extra : moz-landing-system : lando
This patch is generated by running the following script under layout/,
and then manually delete the FIXME comment in LayoutConstants.h
#!/bin/bash
function rename() {
find .\
-type f\
! -path "./obj*"\
! -path "./.git"\
! -path "./.hg"\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -e "s/$1/$2/g" "{}" \;
}
rename NS_INTRINSIC_WIDTH_UNKNOWN NS_INTRINSIC_ISIZE_UNKNOWN
Differential Revision: https://phabricator.services.mozilla.com/D29746
--HG--
extra : moz-landing-system : lando
We always include the combinator for pseudo-elements now (not including it was
just an optimization) in order to not match when nested pseudo-elements are
involved.
We could add a more generic check in `matches_simple_selector` like:
```
if element.is_pseudo_element() {
match *selector {
Component::PseudoElement(..) |
Component::NonTSPseudoClass(..) => {},
_ => return false,
}
}
```
But even that wouldn't be enough to make selectors like `:hover::marker` not
match on the `::before::marker` pseudo-element, plus that code is really hot.
So for now do the check on the `next_element_for_combinator` function. It's a
bit hacky but it's the best I could came up with...
While at it, simplify some checks to use is_pseudo_element() instead of
implemented_pseudo_element() directly.
Only the Rust patch as-is would make markers for ::before and ::after on list
items not show up, so we also need to switch ::marker to use ProbeMarkerStyle()
rather than ProbePseudoElementStyle(), since the marker should exist even if it
matches no rules.
Differential Revision: https://phabricator.services.mozilla.com/D27529
--HG--
extra : moz-landing-system : lando
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
--HG--
extra : moz-landing-system : lando
Per the discussion in:
https://groups.google.com/d/msg/mozilla.dev.platform/P79pwa9z5m8/iPYPAWPHCAAJ
They should be CamelCase, and that's what most of them already do. This converts
the rest, which are a few.
For the ones that already used `e` or `k` prefixes, I've mostly done:
for file in $(rg Type::e layout | cut -d : -f 1 | sort | uniq); do sed -i 's#Type::e#Type::#g' $file; done
For the ones that used uppercase, I've removed the prefix if it was already in
the type name, and turn them into CamelCase.
Depends on D28680
Differential Revision: https://phabricator.services.mozilla.com/D28681
--HG--
extra : moz-landing-system : lando
This patch moves some `enum` in `nsIPresShell` which are in public scope into
`mozilla` namespace and change them as `enum class`es.
Unfortunately, only "where to scroll" enum is just defines constants of
percentages of scroll destination. Therefore, this patch makes only them
as `static const`.
Differential Revision: https://phabricator.services.mozilla.com/D28606
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
Frederic Wang
Andreea Pavel
Frédéric Wang
Jonathan Kew
Coroiu Cristina
Mihai Alexandru Michis
Oana Pop Rus
L. David Baron
RuchikaGosain
Brindusan Cristian
Alexis Beingessner
Victor Porof
Boris Zbarsky
Emilio Cobos Álvarez
Matt Woodrow
Cameron McCormack
Miko Mynttinen
Ting-Yu Lin
Noemi Erli
Masayuki Nakano
Brian Grinstead