I want to enable in Nightly to evaluate (in the medium term) shipping it without
the part forwarding, once the cascade order and importance issues are fixed, and
that we pass all the tests that don't involve forwarding.
That is, I want to monitor whether having ::part() causes compat issues or not.
Depends on D32648
Differential Revision: https://phabricator.services.mozilla.com/D32649
--HG--
extra : moz-landing-system : lando
This should make all the pieces come together.
Note that we don't need to look at the snapshot for ::part() for now (other than
when selector-matching normally) because I decided to just restyle the element
for now when the part attribute changes.
::part() can't affect descendants anyway (as long as we don't do the forwarding
stuff), and eager pseudo-elements are handled during the normal element restyle,
so it seems to me that adding all the complexity that we have for classes to
part may not be worth it at least yet.
Depends on D32647
Differential Revision: https://phabricator.services.mozilla.com/D32648
--HG--
extra : moz-landing-system : lando
I still haven't implemented each_part(), so this will do nothing yet.
The cascade order stuff is fishy, I know, and I'll fix in a followup if it's
fine with you. I moved the sorting of the rules to rule_collector, since it
seemed to me it was better that way that duplicating the code, and those
SelectorMap functions only have a single caller anyway.
Depends on D32646
Differential Revision: https://phabricator.services.mozilla.com/D32647
--HG--
extra : moz-landing-system : lando
Unlike for :host() or ::slotted(), or regular rules, we don't need a whole
SelectorMap<>, so gotta make the code a bit more generic.
Depends on D32645
Differential Revision: https://phabricator.services.mozilla.com/D32646
--HG--
extra : moz-landing-system : lando
This grows the selector struct, but only in 32-bit, since in 64-bit we take
space from the alignment padding that we're paying due to having the size of the
slice as a word.
Depends on D32644
Differential Revision: https://phabricator.services.mozilla.com/D32645
--HG--
extra : moz-landing-system : lando
This uses the bit added for tracking part attributes in order to avoid doing
wasted work.
Depends on D32643
Differential Revision: https://phabricator.services.mozilla.com/D32644
--HG--
extra : moz-landing-system : lando
Still does nothing, since we still do not collect part rules, but this is all
the plumbing that should allow us to invalidate parts when attributes or state
change on their ancestors.
Depends on D32641
Differential Revision: https://phabricator.services.mozilla.com/D32642
--HG--
extra : moz-landing-system : lando
These are owned by the element and not referenced from the stylesheets.
They're referenced from the rule tree, but the rule nodes don't measure their
style source (since they're non-owning).
So unconditionally reporting them even though it's a refcounted object is ok.
While at it, remove some other fields from the old style system that are no
longer used.
Differential Revision: https://phabricator.services.mozilla.com/D34014
--HG--
extra : moz-landing-system : lando
It looks like bug 1547939 will stick, given how fast the other regressions came
in for bug 1337655.
We haven't seen any regression from this, and it seems unlikely that we'd want
this code back.
This blocks further improvements to the style system. Simplifying this code
allows me to remove all the conversion code for gradients.
Let me know if you think it's premature and I'm happy to wait, but I really want
to see this code gone :)
Differential Revision: https://phabricator.services.mozilla.com/D33820
--HG--
extra : moz-landing-system : lando
From this point on, the webkit-prefixed CSS features that were previously
protected by this pref will now be unconditionally enabled.
Differential Revision: https://phabricator.services.mozilla.com/D33807
--HG--
extra : moz-landing-system : lando
support for from-font listed in the CSS spec will be implemented in a later bug
Differential Revision: https://phabricator.services.mozilla.com/D33233
--HG--
extra : moz-landing-system : lando
support for from-font listed in the CSS spec will be implemented in a later bug
Differential Revision: https://phabricator.services.mozilla.com/D33233
--HG--
extra : moz-landing-system : lando
They're not used internally either, so remove all ability to address them.
I haven't removed the implementation yet, as some of them are quite complex, and
I don't have a mac / windows build. We should do that when this hits release
though.
Differential Revision: https://phabricator.services.mozilla.com/D32488
--HG--
extra : moz-landing-system : lando
It is indeed the most common case according to a bit of measurement.
A non-atypical example from GitHub for example:
> Rule tree stats:
> 0 - 340
> 1 - 1403
> 2 - 28
> 3 - 8
> 4 - 2
> 6 - 1
> 7 - 3
> 8 - 2
> 12 - 2
> 14 - 1
> 41 - 1
> 45 - 1
> 67 - 1
> 68 - 1
Differential Revision: https://phabricator.services.mozilla.com/D33351
--HG--
extra : moz-landing-system : lando
support for from-font listed in the CSS spec will be implemented in a later bug
Differential Revision: https://phabricator.services.mozilla.com/D33233
--HG--
extra : moz-landing-system : lando
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
I need to profile this a bit more, but talos was pretty happy about this, and it
solves the known performance issues here such as the test-case from bug 1483963
for example. This also gets rid of a bunch of unsafe code which is nice.
This still keeps the same GC scheme, removing the key from the hashmap when
needed. I kept those as release assertions, but should probably be turned into
debug-only assertions.
Differential Revision: https://phabricator.services.mozilla.com/D6801
--HG--
extra : moz-landing-system : lando
We cannot compile with just feature(gecko + debug_assertions), since that's how
debug rusttests get compiled and they don't have the refcount logging stuff.
We were getting away with it for the pre-existing usage of the style crate,
because it wasn't used during any test and presumably the linker didn't
complain. But servo_arc is definitely used in tests.
Differential Revision: https://phabricator.services.mozilla.com/D32691
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
--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
