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
Except retrieving from weak reference, `nsIFrame` should treat
`mozilla::PresShell` directly rather than via `nsIPresShell`.
Differential Revision: https://phabricator.services.mozilla.com/D26388
--HG--
extra : moz-landing-system : lando
`nsPresContext` should use `mozilla::PresShell` directly instead of
`nsIPresShell`. This patch makes it.
Unfortunately, `nsPresContext` and `nsIFrame` have `PresShell()`. Therefore,
we cannot use `PresShell*` in its methods so that this patch uses `mozilla::`
namespace prefix.
It might be better to rename them as `PresShellPtr()` in another bug.
Differential Revision: https://phabricator.services.mozilla.com/D25721
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
--HG--
extra : moz-landing-system : lando
This allows us to reduce #include usage of the massive gfxFont.h header,
and keeps this specialized kind of TextRange struct local to where it's used.
Differential Revision: https://phabricator.services.mozilla.com/D22904
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
`*Inlines.h` shouldn't be included by another header file, but `nsPresContext.h`
does it. This causes include-hell which blocks the following fix.
Additionally, it causes an include hell between `PresShell.h` vs.
`nsIPresShell.h` and `nsPresContext.h if `Document.h` includes `PresShell.h`.
Therefore, this patch also solves this include hell with adding
`nsPresContextInlines.h`.
Differential Revision: https://phabricator.services.mozilla.com/D25333
--HG--
extra : moz-landing-system : lando
It's a global object, it doesn't have to be stored in nsFont. Pass it from the
caller like the user font set and co.
Depends on D20141
Differential Revision: https://phabricator.services.mozilla.com/D20142
This is more consistent with what the Rust bits of the style system do, and
removes a pointer from ComputedStyle which is always nice.
This also aligns the Rust bits with the C++ bits re. not treating xul pseudos as
anonymous boxes. See the comment in nsTreeStyleCache.cpp regarding those.
Can't wait for XUL trees to die.
Depends on D19001
Differential Revision: https://phabricator.services.mozilla.com/D19002
--HG--
extra : moz-landing-system : lando
It's a global object, it doesn't have to be stored in nsFont. Pass it from the
caller like the user font set and co.
Depends on D20141
Differential Revision: https://phabricator.services.mozilla.com/D20142
--HG--
extra : moz-landing-system : lando
This patch makes do_QueryFrame() accept const frame pointer e.g.
"const nsIFrame*", and also helps eliminate a few const_cast in Part 3.
Note that the fast path of do_QueryFrame is const-correct, but the slow
path is not (due to nsIFrame::QueryFrame() returns void*).
For example:
```
const nsIFrame* f;
nsBlockFrame* a = do_QueryFrame(f); // fast path, compile error.
nsIAnonymousContentCreator* b = do_QueryFrame(f); // slow path, still compiles.
```
Differential Revision: https://phabricator.services.mozilla.com/D19860
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Per our discussion, this patch splits out the state management bits of
WebRenderLayerManager, allowing for them to be maintained per-document.
Differential Revision: https://phabricator.services.mozilla.com/D13577
--HG--
extra : moz-landing-system : lando
Converted NS_STYLE_BORDER_STYLE_* consts to enum class. Updated corresponding values to enum class. reduced BCCornerInfo struct values to fit StyleBorderStyle values inside struct. Added defaults to switches that do not fully cover all instances of StyleBorderStyle.
Summary:
The behavior the WG proposed is way more subtle than what that bug implements,
including:
* Implementing two logical overflow longhands.
* Expanding the overflow shorthand to different longhands depending on the
syntax of that.
Meanwhile, Blink hasn't done the swap and will ship the same behavior that we
shipped in Firefox 61 (bug 1453148), that is, overflow-x, then overflow-y.
So I think lacking a clear way forward we should revert this change and preserve
our shipped behavior.
Reviewers: dbaron!
Tags: #secure-revision
Bug #: 1492567
Differential Revision: https://phabricator.services.mozilla.com/D6317
All classes deriving from nsIFrame that did not have any subclasses themselves
(at the time of writing this patch) have been marked with `final`.
Some other Layout classes have also been made final, but this was opportunistic
while working on nsIFrame subclasses, and is definitely not exhaustive, further
patches welcome; refer to bug 1332680.
Advantages of marking a class final include:
- Allowing the compiler to devirtualize some method calls (i.e., calling
virtual functions directly instead of going through the vtable),
- Indicating that the class is not currently subclassed,
- Preventing subclassing without being aware that this would remove the
finalization benefits of the parent class.
`final` does not signify that these classes should *never* be subclassed, this
is left for developers to decide.
Differential Revision: https://phabricator.services.mozilla.com/D5020
--HG--
extra : moz-landing-system : lando
For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3370
--HG--
extra : moz-landing-system : lando
This is needed for patch 4.
This is based both on the wording in the spec and the discussion in
https://github.com/w3c/csswg-drafts/issues/2987, and also doesn't
support them for nsMathMLContainerFrame, which is similar to inlines and
ruby.
Differential Revision: https://phabricator.services.mozilla.com/D2815
--HG--
extra : rebase_source : b7e23fb248fa34957ca2d539134e872f5a03f5a8
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Jonathan Kew
Frédéric Wang
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
arthur.iakab
Dorel Luca
Dan Glastonbury
Ryan Hunt
Ciure Andrei
Kris Maglione
Ehsan Akhgari
Doug Thayer
Sylvestre Ledru ext:(%20and%20Karl%20Tomlinson%20%3Ckarlt%2B%40karlt.net%3E)
Mark Banner
Cosmin Sabou
Jonathan Watt
Kristen Wright
Jeff Muizelaar
Andreea Pavel
Margareta Eliza Balazs
Jean-Luc Bonnafoux
Zhang Junzhi
Gerald Squelart
Daniel Holbert
Csoregi Natalia
Xidorn Quan
Jeff Gilbert
Chris Peterson
Andi-Bogdan Postelnicu
Jeff Walden