This patch invalidates the style for `::selection`, which will restore the
behavior before the regression.
However, it's still not quite correct, because repaint is not triggered. Given
that `::selection` requires some major change to implement
https://github.com/w3c/csswg-drafts/issues/2474, we can address this problem
later.
Differential Revision: https://phabricator.services.mozilla.com/D35305
This patch produces the following serialization:
```
input | computed value
------------------------------
1. "auto" "auto"
2. "auto auto" "auto"
3. "15px auto" "15px"
4. "15px" "15px"
```
i.e. If the second value is 'auto', then it's omitted from our serialization,
because it's implied.
Besides, we update the wpt to address this spec issue:
https://github.com/w3c/csswg-drafts/issues/2574
Differential Revision: https://phabricator.services.mozilla.com/D35510
The style system already atomizes all CustomIdent values, which means that we're
just wasting memory and CPU by doing string copies all over the place.
This patch fixes it. This also simplifies further changes to use as much of the
rust data structures as possible.
I had to switch from nsTHashtable to mozilla::HashTable because the former
doesn't handle well non-default-constructible structs (like NamedLine, which
now has a StyleAtom, which is not default-constructible).
Differential Revision: https://phabricator.services.mozilla.com/D35119
Right now we do a lot of useless string copying. In order to avoid transcoding
to utf-16 during layout, make sure to use nsCString at a few related places.
I may revisit this since we're storing other line names as atoms in some places.
So it may be better to just use atoms everywhere.
But that'd be a different patch either way.
Differential Revision: https://phabricator.services.mozilla.com/D35117
Should not serialize default shape-outside circle() function radius.
The ToCss impl of Circle and Ellipse turn out to be identical in specified and computed value, thus move them to generics.
Differential Revision: https://phabricator.services.mozilla.com/D35183
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.
Differential Revision: https://phabricator.services.mozilla.com/D32649
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.
Differential Revision: https://phabricator.services.mozilla.com/D32648
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.
Differential Revision: https://phabricator.services.mozilla.com/D32647
Unlike for :host() or ::slotted(), or regular rules, we don't need a whole
SelectorMap<>, so gotta make the code a bit more generic.
Differential Revision: https://phabricator.services.mozilla.com/D32646
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.
Differential Revision: https://phabricator.services.mozilla.com/D32642
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
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
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
Remove unused code (4/4)
<!-- Please describe your changes on the following line: -->
Fourth and final PR in a series of PRs to remove unused/dead code from servo, powered by an (upcoming) tool of mine. Please take a look and tell me if you want to keep something.
* First PR: #23477
* Second PR: #23498
* Third PR: #23499
Shortstat of the combined PR series:
```
47 files changed, 7 insertions(+), 805 deletions(-)
```
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they only remove dead code
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23532)
<!-- Reviewable:end -->
style: sync changes from mozilla-central
See each individual commit for details. This also cherry-picks #23463 with a few fixes that were needed in Gecko-only code.
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23503)
<!-- Reviewable:end -->
Remove unused code (3/N)
<!-- Please describe your changes on the following line: -->
Third PR in a series of PRs to remove unused/dead code from servo, powered by an (upcoming) tool of mine. Please take a look and tell me if you want to keep something.
* First PR: #23477
* Second PR: #23498
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because they only remove dead code
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/23499)
<!-- Reviewable:end -->
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
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
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 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
