This reverts the relevant bits from #21746 so that style and dependencies can
build with stable.
This is important because:
* `selectors` is a published crate.
* Gecko compiles with stable (more or less).
I reviewed that PR under the assumption that the union feature was stable, since
untagged unions are stable since 1.19, but turns out that smallvec uses non-Copy
types in unions, which are still unstable.
This leaves the union feature used on Servo, so that it gets testing, taking
advantage of features being additive.
This cherry-picks servo/servo#21788.
We had a mix of 0.6.2 and 0.6.5 (which is the current release),
this unifies to the latest version. It also enables the union
feature which removes the discriminant, reducing memory usage.
This cherry-picks servo/servo#21746.
According to the new svg 2 spec update (#543), we flip the flag half way for
path interpolation.
Differential Revision: https://phabricator.services.mozilla.com/D6192
--HG--
extra : moz-landing-system : lando
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
I always see a bunch of time in our profiles in the iterator over the
declarations, this ensures it's not something dumb.
I suspect it's just a bunch of cache misses from walking the rule tree but in
any case this is consistent with the other getters we have and such.
Differential Revision: https://phabricator.services.mozilla.com/D5971
--HG--
extra : moz-landing-system : lando
I think it used to be the case that all PropertyDeclaration variants had a
DeclaredValueOwned<T> inside. But that's no longer the case, so this abstraction
seems less useful now.
Differential Revision: https://phabricator.services.mozilla.com/D5978
--HG--
extra : moz-landing-system : lando
There's no good reason we construct a DeclaredValue as an intermediate step.
Differential Revision: https://phabricator.services.mozilla.com/D5977
--HG--
extra : moz-landing-system : lando
That way I can unify Servo's and Gecko's Cargo.toml files.
This is the only conflict that exists since a while ago, and it causes
continuous manual merges when I sync changes around.
This moves it to ports/geckolib, which works equally well and isn't in the Servo
repo.
Differential Revision: https://phabricator.services.mozilla.com/D5957
--HG--
extra : moz-landing-system : lando
There are a few mentions of nsRuleNode left but they are mostly
historical references so it makes sense to keep them.
Differential Revision: https://phabricator.services.mozilla.com/D5505
We define the standalone types for using derive macro easily and overriding
the behaviors of this traits. This could avoid defining the general
behavior of booleans.
Depends on D4788
Differential Revision: https://phabricator.services.mozilla.com/D4813
--HG--
extra : moz-landing-system : lando
Here, we change the animation type of offset-path as ComputedValue, so
we could do animation on it. Also enable the wpt for offset-path
interpolation. In test_transition_per_property.html, we add some basic tests
ifor offset-path.
ToAnimatedZero for PathCommand will be dropped later.
Because the animations of arcs with mismatched flags are fallen back to
discrete animations, the result of getComputedValue is not normalized in this
case. This makes some wpt failed even though the progress is 100%.
Depends on D4786
Differential Revision: https://phabricator.services.mozilla.com/D4787
--HG--
extra : moz-landing-system : lando
Implement Animate trait for SVGPathData.
The basic idea is: we normalize |this| and |other| svg paths, and then
do interpolation on the normalized svg paths. The normalization is to
convert relative coordinates into absolute coordinates, so we could do
real number interpolation on each path command directly.
In this patch, we also make |clip-path:path()| animatable.
Differential Revision: https://phabricator.services.mozilla.com/D4786
--HG--
extra : moz-landing-system : lando
Looks like this produces sensible results for interpolation with 0, though I'm
not really convinced about the results from, let's say, 1px to 2000px in the
attached test-case, I would've expected a linear interpolation from that to go
through normal length interpolation.
css-transforms-1 says:
> Two transform functions with the same name and the same number of arguments
> are interpolated numerically without a former conversion. The calculated
> value will be of the same transform function type with the same number of
> arguments.
>
> Special rules apply to <matrix()>.
Which is what we do... I was going to file a spec issue but turns out that it's
already addressed in css-transforms-2:
https://drafts.csswg.org/css-transforms-2/#interpolation-of-transform-functions
Which says:
> The transform functions <matrix()>, matrix3d() and perspective() get
> converted into 4x4 matrices first and interpolated as defined in section
> Interpolation of Matrices afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D4942
--HG--
extra : moz-landing-system : lando
Add a preference, layout.css.clip-path-path.enabled, for |clip-path:path()|.
Differential Revision: https://phabricator.services.mozilla.com/D4965
--HG--
extra : moz-landing-system : lando
This also removes one of my FIXMEs from when I was looking at this code.
We don't seem to have a pre-existing test for this feature, sigh. I'll try to
write one if I have cycles for it...
Note that it not applying XBL rules is a feature, given the current state of
affairs. Video controls and such are right now unusable with no styles enabled.
Differential Revision: https://phabricator.services.mozilla.com/D4795
--HG--
extra : moz-landing-system : lando
We always serialize as an atom, which is the previous behavior (though previous
code was using string escaping which I think was not totally sound either...).
Differential Revision: https://phabricator.services.mozilla.com/D4753
--HG--
extra : moz-landing-system : lando
We're wasting 1kb there, which is kind of stupid.
The only advantage of using a bloom filter is that memory usage doesn't increase
even if there's a gazillion attribute selectors and such. But:
* For IDs we already have a bunch of data structures for invalidation and such
which key on the id, so the bloom filter would be a very minor thing.
* For attribute selectors we don't have such a data structure, but if people
used a gazillion attribute selectors we should!
Differential Revision: https://phabricator.services.mozilla.com/D4668
--HG--
extra : moz-landing-system : lando
So that we don't waste a bunch of memory with stuff like <svg:use>. I
plan to shrink AuthorStyles further, but this should help regardless, and isn't
very complex.
Differential Revision: https://phabricator.services.mozilla.com/D4618
--HG--
extra : moz-landing-system : lando
We only care about ascii char for svg path, so we could parse the string
as byte slice.
Differential Revision: https://phabricator.services.mozilla.com/D4168
--HG--
extra : moz-landing-system : lando
For now, |clip-path: path()| is chrome-only, and not for shape-outside,
so we only implement the parser for clip-path. Besides, I didn't put
path() in BasicShape because path() doesn't use the reference box to
resolve the percentage or keywords (i.e. SVG path only accept floating
point or integer number as the css pixel value). Therefore, I add it into
ShapeSource, instead of BasicShape.
Differential Revision: https://phabricator.services.mozilla.com/D3633
SVGPathData will be used by clip-path and offset-path (and/or more on the
properties which support <basic-shape>). Therefore, let's move
SVGPathData out of motion.rs.
Differential Revision: https://phabricator.services.mozilla.com/D3631
Just a minor fix to use cbindgen to avoid the conversion between
basic_shape::FillRule and mozilla::StyleFillRule.
Differential Revision: https://phabricator.services.mozilla.com/D4171
--HG--
extra : moz-landing-system : lando
The implementation of ToCSS for Polygon has some rule, and we could use skip_if
to handle and serialization of fill-rule. However, we should derive ToCSS for
the pair of LengthOrPercentages, so define a new type for it.
Differential Revision: https://phabricator.services.mozilla.com/D4153
--HG--
extra : moz-landing-system : lando
This was consistently faster in the benchmark (even when counters were disabled,
which was slightly suspicious, but...).
Anyway, it's not really much code, most of it is FFI copy-pasta.
Differential Revision: https://phabricator.services.mozilla.com/D3874
Mostly testing that they work, and that they record what we expect them to
record, that is, the actual property that was parsed, and not the properties
that it'd resolve or expand to.
That may be another tricky part for CSSOM, I think style setters would fail an
alias test if implemented with the current setup (we do the property lookup in
C++).
Differential Revision: https://phabricator.services.mozilla.com/D3829
Still not hooked into telemetry, I talked with :janerik and :gfritzsche about
that, but test incoming!
This intentionally doesn't handle CSSOM and such for now, will file followups
for those, though should be trivial.
I want to unify / clean up how we do the use counters and the error reporting
stuff for CSSOM, since the current function call still shows up in profiles,
but that should be a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D3828
There are a lot of duplicates, so we use macro to refine them.
Depends on D2963
Differential Revision: https://phabricator.services.mozilla.com/D2966
--HG--
extra : moz-landing-system : lando
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
- Parse SVG Path String into SVGPathData (in Rust).
- Use cbindgen to make sure the layout of PathCommand and StylePathCommand, and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
- Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Depends on D2962
Differential Revision: https://phabricator.services.mozilla.com/D2963
--HG--
extra : moz-landing-system : lando
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
* Parse SVG Path String into SVGPathData (in Rust).
* Use cbindgen to make sure the layout of PathCommand and StylePathCommand,
and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
* Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part
will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Differential Revision: https://phabricator.services.mozilla.com/D2963
Port `width`, and also add the `scan` media feature so I don't need to add
ugliness just to workaround the unused keyword_evaluator macro.
This is not part of the Gecko build in any case.
To support that, this patch also does the following.
- Removes the insert(), remove() and might_contain() methods, because they are
specialized versions of insert_hash(), remove_hash(), and
might_contain_hash(), and they are only used by tests within this file.
- Moves hash() from the top level into create_and_insert_some_stuff().
- Changes create_and_insert_some_stuff() so that instead of hashing consecutive
integers, it instead hashes stringified consecutive integers, which matches
real usage a little better.
- Raises the false_positives limit a little to account for the above changes.
--HG--
extra : rebase_source : f839ff86986d5c8a17506a808ba676f69c7ef407
Now that :-moz-system-metric is gone, there's no real reason for the atoms to
be separate.
Differential Revision: https://phabricator.services.mozilla.com/D3497
--HG--
extra : moz-landing-system : lando
This moves most of the code to be Rust, except potentially some evaluator
functions, and allows to unblock the use case from any-hover / any-pointer and
remove nsMediaFeatures.
Differential Revision: https://phabricator.services.mozilla.com/D2976
We match with AllLinksVisitedAndUnvisited for style invalidation, and we already
do a subtree restyle because :visited matching doesn't depend on the actual
element state.
So all this stuff is just not needed. The comment points to the attribute tests
in bug 1328509, but those still trivially pass with this change.
I think this was unneeded since I introduced AllLinksVisitedAndUnvisited, or
maybe since https://github.com/servo/servo/pull/19520. In any case it doesn't
really matter, and I already had done this cleanup in my WIP patches for
bug 1406622, but I guess this is a slightly more suitable place to land them :)
Differential Revision: https://phabricator.services.mozilla.com/D3305
We force a repaint from ContentStateChangedInternal if visited links are
disabled, and that's observable. Let's cut it off as early as we can to avoid
timing attacks even when :visited is disabled.
Differential Revision: https://phabricator.services.mozilla.com/D3304
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
1. We will add more shape-like types in the future, so it's better to
use union to reduce the memory usage.
2. Those shape-like types are mutual exclusive, so we could use union to
wrap them.
Differential Revision: https://phabricator.services.mozilla.com/D2746
--HG--
extra : moz-landing-system : lando
It used to be this way because of lifetime issues (plus the shadow
datas were in RwLocks at some point IIRC). Now we guarantee that as long as the
element is away the cascade data is as well, so we don't need to thread it
around.
Differential Revision: https://phabricator.services.mozilla.com/D2768
--HG--
extra : moz-landing-system : lando
We only have this so that ::-moz-placeholder keeps serializing as
::-moz-placeholder, but I don't think anybody really cares.
Edge aliases ::-webkit-input-placeholder to ::-ms-input-placeholder at parse
time as well, as can be seen in:
```
let s = document.createElement('style');
s.innerHTML = `input::-webkit-input-placeholder { color: red };`;
document.body.appendChild(s);
document.body.innerHTML = s.sheet.cssRules[0].cssText;
```
And I think this is more consistent with what we do for CSS properties that are
aliases.
Differential Revision: https://phabricator.services.mozilla.com/D2595
MozReview-Commit-ID: 3ImDWamJhxh
This saves about 37 KiB of memory across the UA style sheets.
MozReview-Commit-ID: EoZnlmyWwxX
--HG--
extra : rebase_source : cd8ef0ba838618f9a4583b7d9896caa3a0602199
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
The '-moz-menulist-button' value currently behavies identically to the
'menulist-button' value. This is not implemented as an alias because later
patches in this patch series will change the behavior of our pre-existing
'menulist-button' value to more closely match what Chrome does.
--HG--
extra : rebase_source : b66bf6427db5be2eb12f4e0aa36d22a4da46555a
Always assume allowed-for-all-content. There are a couple callers which weren't
doing that:
* A unit test -> removed.
* ComputeAnimationDistance: Used for testing (in transitions_per_property), and
for the animation inspector. The animation inspector shouldn't show
non-enabled properties. The transitions_per_property test already relies on
getComputedStyle stuff which only uses eForAllContent.
* GetCSSImageURLs: I added this API for the context menu page and such. It
doesn't rely on non-enabled-everywhere properties, it was only using
eInChrome because it was a ChromeOnly API, but it doesn't really need this.
Differential Revision: https://phabricator.services.mozilla.com/D2514
MozReview-Commit-ID: 4VOi5Su3Bos
And general Element logging. We now print all the attributes for comparison.
If this turns out to be too verbose we can change it to diff them or something.
Differential Revision: https://phabricator.services.mozilla.com/D2471
MozReview-Commit-ID: 1Gl9AumdnvZ
:root can't change without getting unbound from the tree so no fancy stuff other
than that needed.
This removes a lot of revalidation and attribute invalidation matching from the
Chrome, and looks like it should be a good idea in general.
Differential Revision: https://phabricator.services.mozilla.com/D2462
MozReview-Commit-ID: 9B0EO9teczi
We have a different order in nsCSSPropertyId for no good reason. The only
invariant there is that longhands come before shorthands, and shorthands before
aliases.
Luckily that's also an invariant that NonCustomPropertyId has, so we can reuse
them.
Differential Revision: https://phabricator.services.mozilla.com/D2463
MozReview-Commit-ID: 1hsQu6hmqiN
The patch at bug 1478391 comment 6 changed the way the math in Scrollbarbutton*
worked, which pretty surely caused this.
Restore the original order and math to be the same as before bug 1478391.
MozReview-Commit-ID: CK3iOqeX2NW
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