This builds on bug 1428676 and introduces StyleAppearance, which replaces the
NS_THEME_* constants.
Really sorry for the size of the patch.
There's a non-trivial change in the gtk theme, which I submitted separately as
bug 1478385.
Differential Revision: https://phabricator.services.mozilla.com/D2361
MozReview-Commit-ID: DiSmMWK7Krp
We use the same setup WR uses, which is checking-in the files.
But I think it's much better than keeping the two things in sync manually :)
When you add a new value, you need to add it to the rust source, then run the
command, but since it doesn't need to build the style crate (it uses the Rust
AST, doesn't build) there's no problem.
Differential Revision: https://phabricator.services.mozilla.com/D2354
MozReview-Commit-ID: DnXkNAzP54H
We use the same setup WR uses, which is checking-in the files.
But I think it's much better than keeping the two things in sync manually :)
When you add a new value, you need to add it to the rust source, then run the
command, but since it doesn't need to build the style crate (it uses the Rust
AST, doesn't build) there's no problem.
Differential Revision: https://phabricator.services.mozilla.com/D2354
MozReview-Commit-ID: DnXkNAzP54H
The values in the boolean context depend on its feature. For examples, in the
case of prefers-reduced-motion 'no-preference' means false and 'reduced' mean
true in the boolean context, whereas in the case of prefers-contrast
'no-preference' means false and other two values, 'high' and 'low' means true
in the boolean context. To support it we introduce a child struct of
nsCSSKTableEntry that has an additional field representing the value in the
boolean context and use it when we have no specified value in the media feature
(i.e. in the boolean context).
MozReview-Commit-ID: 79HiW8l5ous
I put Balance as the first item in StyleColumnFill because it is the default
value.
MozReview-Commit-ID: A4DVMLL6XBa
--HG--
extra : rebase_source : 8c8d07b724bcd49dd4f4057fcbf0ccd46ed591ff
NS_STYLE_COLUMN_COUNT_UNLIMITED is unused, so I remove it.
MozReview-Commit-ID: HLHLn9ZbkUY
--HG--
extra : rebase_source : 9bf00e1db00051c4454719e205633717fabde050
Summary:
This fixes a couple fuzz bugs and prevents special-casing <svg:use> even more in
bug 1431255.
Unfortunately not as many hacks went away as I'd have hoped, since we still need
to match document rules, see the linked SVGWG issues.
But blocks_ancestor_combinators goes away, which is nice since it's on a very
hot path.
Test Plan: WPT for style invalidation, covered by existing tests otherwise.
Reviewers: heycam
Tags: #secure-revision
Bug #: 1450250
Differential Revision: https://phabricator.services.mozilla.com/D2154
MozReview-Commit-ID: C4mthjoSNFh
Thought I had to update this as well, but nope. When basically any style changes
we already update transitions.
needs_transitions_update already handles the physical mapping changing by
checking whether any transition for the physical property remain there or not.
MozReview-Commit-ID: 6vKwal4yzRU
The setup is that AnimationValue only contains physical properties, and
we physicalize when building keyframes and transitions.
MozReview-Commit-ID: 9dI20N0LFrk
If we have a rotate axis whose length is extremely large, we will get an
infinite value, and its normalized vector is a zero vector, instead of an
unit vector, i.e. (x/inf, y/inf, z/inf) == (0, 0, 0).
The solution is: we scale the vector, so the length becomes a finite value,
and we could get a valid unit vector. Therefore, we use
a different normalization method, robust_normalize().
MozReview-Commit-ID: L8SteFe09aO
--HG--
extra : rebase_source : 4568c8bf906a9246e4ef13672a9ed541852b974a
In order to drop old euclid version, we still need to bump euclid for
plane-split and gfx/*. However, it needs more update and is not related to
this bug, so let's do that in other place. Here, we bump euclid to
0.18.1, and update style/values/generics/transform.rs for it.
MozReview-Commit-ID: JfNAxkR8wgs
--HG--
rename : third_party/rust/euclid/.cargo-checksum.json => third_party/rust/euclid-0.17.3/.cargo-checksum.json
rename : third_party/rust/euclid/Cargo.toml => third_party/rust/euclid-0.17.3/Cargo.toml
rename : third_party/rust/euclid/src/homogen.rs => third_party/rust/euclid-0.17.3/src/homogen.rs
rename : third_party/rust/euclid/src/length.rs => third_party/rust/euclid-0.17.3/src/length.rs
rename : third_party/rust/euclid/src/lib.rs => third_party/rust/euclid-0.17.3/src/lib.rs
rename : third_party/rust/euclid/src/macros.rs => third_party/rust/euclid-0.17.3/src/macros.rs
rename : third_party/rust/euclid/src/point.rs => third_party/rust/euclid-0.17.3/src/point.rs
rename : third_party/rust/euclid/src/rect.rs => third_party/rust/euclid-0.17.3/src/rect.rs
rename : third_party/rust/euclid/src/rotation.rs => third_party/rust/euclid-0.17.3/src/rotation.rs
rename : third_party/rust/euclid/src/scale.rs => third_party/rust/euclid-0.17.3/src/scale.rs
rename : third_party/rust/euclid/src/side_offsets.rs => third_party/rust/euclid-0.17.3/src/side_offsets.rs
rename : third_party/rust/euclid/src/size.rs => third_party/rust/euclid-0.17.3/src/size.rs
rename : third_party/rust/euclid/src/transform2d.rs => third_party/rust/euclid-0.17.3/src/transform2d.rs
rename : third_party/rust/euclid/src/transform3d.rs => third_party/rust/euclid-0.17.3/src/transform3d.rs
rename : third_party/rust/euclid/src/trig.rs => third_party/rust/euclid-0.17.3/src/trig.rs
rename : third_party/rust/euclid/src/vector.rs => third_party/rust/euclid-0.17.3/src/vector.rs
extra : rebase_source : 0594429c74c7391f80b4e291cd7fe9cbddd72b33
To be consistent, use the block indentation the rest of the Rust code uses.
Differential Revision: https://phabricator.services.mozilla.com/D1906
--HG--
extra : moz-landing-system : lando
... and cleanup unused keywords / getters using the scripts in
layout/style/tools
Differential Revision: https://phabricator.services.mozilla.com/D1901
MozReview-Commit-ID: BRUGcje7X0q
Most of it is automated by:
%s/eStyleContentType_/StyleContentType::/g
%s/nsStyleContentType/StyleContentType/g
But I removed some parentheses by hand.
Differential Revision: https://phabricator.services.mozilla.com/D1900
MozReview-Commit-ID: 3IcirjIYX5p
The 'all' shorthand has shipped a long time ago, so this pref is not needed
anymore.
MozReview-Commit-ID: GND8qSVAfCG
--HG--
extra : rebase_source : 10708e749911fa95554ed423a5782db61df67cd0
This changes the order of properties returned from gCS. The old order
doesn't make much sense, and other browsers don't agree on an identical
order either, so it should be trivial to change it. Also the spec isn't
super clear / useful in this case.
Several -moz-prefixed properties are excluded from the list due to their
being internal. I suspect they are never accessible anyway, so probably
nothing gets changed by this.
MozReview-Commit-ID: 9LfangjpJ3P
--HG--
extra : source : 879a7265c35f51c5954d8a44ccd374a606ecba0e
The EffectSet count does not exactly represent the count what we really need
for AnimationValueMap, but in most cases it matches. For example;
1) The element has two different keyframes animations
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { transform: rotate(360deg); }
}
In this case the number matches.
2) The element has two animations but both keyframes have the same CSS property
@keyframes anim1 {
to { opacity: 0; }
}
@keyframes anim2 {
to { opacity: 0.1; }
}
In this case the number doesn't match, moreover it results more memory than we
ever needed, but this case is presumably less common.
3) The element has an animation having keyframes for two different CSS
properties.
@keyframes anim {
from { opacity: 0; transform: rotate(360deg); }
}
In this kind of cases, the number doesn't match. But even so, this patch
reduces the opportunities that the AnimationValueMap tries to allocate a new
memory (i.e. less opportunities on expanding the map).
Note that when the hash map is expanded, we do allocate a new RawTable with the
new size then replace the old one with the new one [1], so I believe this
change will reduce the crash rate to some extent.
[1] https://hg.mozilla.org/mozilla-central/file/15c95df467be/servo/components/hashglobe/src/hash_map.rs#l734
MozReview-Commit-ID: 6tcF9aqXh7a
--HG--
extra : rebase_source : 366989d3a2756f5a5711503a57f42f3b746d93a5
We will use this number to cap the pre-allocation AnimationValueMap in the next
patch.
MozReview-Commit-ID: Iqq9plbD8Vl
--HG--
extra : rebase_source : 81574095942879078b8289ef52e8e42ed5fa9c3c
After bug 1470163 we have some nasty selectors from mathml.css in every page.
We only want to match them against MathML elements.
This patch brings the global revalidation selectors from 14 to 2 in about:blank.
Also halves the ones from XUL documents.
MozReview-Commit-ID: nOVyknNcVm
This reduces memory usage because we only need one allocation instead of two
for the dynamic atom and its chars, and because we don't need to store a
refcount and a size. It precludes sharing of chars between dynamic atoms, but
we weren't benefiting much from that anyway.
This reduces per-process memory usage by up to several hundred KiB on my
Linux64 box.
One consequence of this change is that we need to allocate + copy in
DOMString::SetKnownLiveAtom(), which could make some things slower.
--HG--
extra : rebase_source : ba4065ea31e509dd985c003614199f73def0596c
Summary:
This should make it easier to report errors, and also reduce codesize.
The reason this was so generic is that error reporting was unconditionally
enabled and was super-hot, but now that's no longer the case after bug 1452143,
so we can afford the virtual call in the "error reporting enabled" case.
This opens the possibility of simplifying a lot the error setup as well, though
this patch doesn't do it.
Test Plan: No behavior change, so no new tests.
Reviewers: xidorn
Bug #: 1469957
Differential Revision: https://phabricator.services.mozilla.com/D1734
MozReview-Commit-ID: F3wTdhX9MB5
We were spuriously reframing the <shadow> because it initially shared style with
the <br>, which ended up being display: none, while the <shadow> should've been
display: contents from the beginning.
lookup_by_rules seems pretty prone to obscure bugs, and also it's pretty
complex... Probably we should try to get rid of it, I'm unconvinced that it's
worth it.
Even with that, in a normal restyle the <details> wouldn't have ended up with a
style. It of course never had it before the reframe because the <shadow> was
display: none, but that doesn't mean it shouldn't have gotten one, since we
detected we needed to go through kids in:
https://searchfox.org/mozilla-central/rev/6eea08365e7386a2b81c044e7cc8a3daa51d8754/servo/components/style/matching.rs#500
That code did happen, but since it's an animation-only restyle, we don't look at
unstyled stuff.
That looks somewhat fishy, but I guess for now it's fine as long as display
isn't animatable.
MozReview-Commit-ID: B6NMSTNOKgK
Do it so that we always try to evaluate the media expression and the modern
syntax last, so that the most specific error message comes up.
MozReview-Commit-ID: 2tqdAsWh6Kh
The only bit from the spec which I haven't implemented to my knowledge is the
bit that allows you to swap the position of the media feature and the value,
because it unnecessarily complicates parsing (we parse the value in terms of the
feature), and I don't think it's useful given how easy it is to switch from,
e.g., `(500px > width)` to `(width <= 500px)`.
I filed https://github.com/w3c/csswg-drafts/issues/2791 about it.
MozReview-Commit-ID: 6xrdVl87S9X
Summary: Looks like I missed this in bug 1464834.
Test Plan: Not part of the build, so no tests.
Reviewers: jwatt
Subscribers: heycam, xidorn
Bug #: 1469244
Differential Revision: https://phabricator.services.mozilla.com/D1679
MozReview-Commit-ID: Bx14lTv6GDD
We may end up looking at a non-flushed AuthorStyles object when looking at
whether attribute changes and such may affect style.
Check the styles are clean to preserve the assertion, since if that happens
before the first flush, we may not have updated the quirks_mode field (and
that's fine).
MozReview-Commit-ID: FgVpiTf4qMr
And move the parsing from a free function to MediaList::parse.
MozReview-Commit-ID: 75ES6I2EEOE
--HG--
extra : rebase_source : acd2be1381409371bf4f151e5b21df713e5d9660
It's possible that both this_weight and other_weght have calculation errors
which are approximately equal to f64::EPSILON.
MozReview-Commit-ID: 8OddG9rI3qd
--HG--
extra : rebase_source : 9c22d17dcfb8efea7276864502344dc4981c358a
Media feature names are converted to lower case before being processed, making
them effectively case-insensitive.
Prefixes ("min-", etc.) and values are already treated in a case-insensitive
manner.
MozReview-Commit-ID: JUeeEQEMIi4
--HG--
extra : rebase_source : 2b990be5894f5575f37fb74a2f6d532c96d15957
The idea is to turn the simple properties into a blacklist instead really soon,
and fix the offending ones soon after, so that only shorthands and properties
with layout dependence (and maybe the scrollbar properties, because the poke at
LookAndFeel) are not serialized by Servo.
MozReview-Commit-ID: JTLNnmXzny8
The idea is to turn the simple properties into a blacklist instead really soon,
and fix the offending ones soon after, so that only shorthands and properties
with layout dependence (and maybe the scrollbar properties, because the poke at
LookAndFeel) are not serialized by Servo.
MozReview-Commit-ID: JTLNnmXzny8
Extract the common parts of `animated::Color` and `computed::Color` out
into `generics::color::Color<T>` that is generic over the type of
RGBA color.
MozReview-Commit-ID: EymSr7aqnAP
--HG--
extra : rebase_source : fb4afe83fc9ab5167ef5d9ecd55cbbb0d3ea8c1d
GCC doesn't like StyleComplexColor with constructor in an anonymous
struct in an anonymous union. Replace the use of a union to access
`mBorder[..]Color` fields as an array with an accessor methods.
MozReview-Commit-ID: 1Wulh1qKYCZ
--HG--
extra : rebase_source : 390b8f852d144a54d9d374bcf3ae70ab6d145d50
Refactored StyleComplexColor to support "complex" blending between
background (numeric) color and foreground color (currentColor).
Made explicit the distinction between numeric, currentColor and a
complex blend in Gecko and Stylo.
This is to support SMIL animation, for example, of the form:
<animate from="rgb(10,20,30)" by="currentColor" ... />
MozReview-Commit-ID: IUAK8P07gtm
--HG--
extra : rebase_source : d3648101c6f65479b21e6f02945731cd5bb57663
Atomic<bool> is implemented in terms of AtomicBase<uint32_t>, because that way
you don't need to depend on atomic 1-byte operations. That means that the rust
bindgen sees it as a u32, not a bool.
It's a bit concerning that the rust code seems to be doing an unsynchronized
read here, but given this is a RelaxedAtomic, that's probably ok.
It's only used for the error path in property parsing, so most of the time is
not useful.
Use the just-introduced NonCustomPropertyId::name to preserve the alias name,
which we were doing by passing the name around.
MozReview-Commit-ID: 46xxZKCoeBB
The six milliseconds spent in Olli's profile make me thing this is not getting
optimized and we expected.
Also move it to NonCustomPropertyId, so it works for aliases properly too.
MozReview-Commit-ID: 4d76Z55ZBEH
This would cause properties to change the value semantics between, e.g.,
@keyframes and non-@keyframes, which would be observable.
It happens not to be observable since the animation-* and transition-*
properties are not allowed in @keyframes, nor have bits in `contain`, and none
of the two properties are allowed in @page. But I think it's the right thing to
do.
This still causes a quirk like a property value in chrome / user origins being
potentially different if the value is specified via CSS var functions. But I
think that is fine.
MozReview-Commit-ID: GhoPt0I34oO
We were working around the lack of alias support during parsing in
TransitionProperty by doing a Gecko lookup. That's a hack and is now gone.
MozReview-Commit-ID: EptUvJNTrZr
Though I think it may be slightly fishy if used in, e.g., a @keyframes block.
For our purposes right now it doesn't make a difference, I think.
MozReview-Commit-ID: A7VCTOqaIuB
Change mStopColor, mFloodColor, and mLightingColor in nsStyleSVGReset.
MozReview-Commit-ID: KMRMtHk1jNK
--HG--
extra : rebase_source : c0c12fa811d17ab6fe0a5ceb31ff32ec585314e0
Currently, NAC always inherits from the closest non-NAC ancestor element,
regardless of whether it is for an element-backed pseudo or not.
This patch changes the inheritance so that for element-backed pseudos, we
inherit from the closest native anonymous root's parent, and for other NAC we
inherit from the parent.
This prevents the following two issues and allows us to remove the
NODE_IS_NATIVE_ANONYMOUS flag:
* Avoiding inheriting from the non-NAC ancestor in XBL bindings bound to NAC.
- This is no longer a problem since we apply the rule only if we're a
pseudo-element, and all pseudo-elements are in native anonymous subtrees.
- This also allows to remove the hack that propagates the
NODE_IS_NATIVE_ANONYMOUS flag from the ::cue pseudo-element from
BindToTree.
* Inheriting from the wrong thing if we're a nested NAC subtree.
- We no longer look past our NAC subtree, with the exception of
::-moz-number-text's pseudo-elements, for which we do want to propagate
::placeholder to.
A few rules from forms.css have been modified because they're useless or needed
to propagate stuff to the anonymous form control in input[type="number"] which
previously inherited from the input itself.
MozReview-Commit-ID: IDKYt3EJtSH
