This builds on top of bug 1910616.
I decided to bubble up the invalidation sets and keep the cascade data
difference in StylesheetInvalidationSet because it felt clearer (it
always was a bit of a wart that we had to pass the root and snapshot map
down to flush).
Now the caller is responsible to flush of course, but I think it's
nicer, specially now that we also merged the shadow dom invalidation
there.
Eventually, it might be worth moving most of the existing sets into the
`CascadeDataDifference`, to be able to track stuff more accurately...
Maybe we can just diff the ElementAndPseudoRules maps? Though given some
pages have hundreds of thousands of rules that might be too much, not
sure. Anyways, one step at a time.
Differential Revision: https://phabricator.services.mozilla.com/D277951
std::unique_ptr's subtleties are hard for bindgen to cope with.
Bug 1973598 was going to make this workaround even uglier by having to figure
out the specific path for std::unique_ptr in the standard library.
Rather than assuming that all usage bindgen sees is simple, explicitly opt in
the few pointers that we need via a new BindgenUniquePtr, and make opaque the
rest.
Differential Revision: https://phabricator.services.mozilla.com/D255568
The raw declaration block might change for a given rule. We need to keep
track of it properly for devtools in order to not lose track of rules.
Could I convince someone from DevTools to write a test for this? :)
Otherwise please point me to the right test to extend / change, and I
can.
Differential Revision: https://phabricator.services.mozilla.com/D230439
Rename getCSSStyleRules now that it can return something else, and
change getCSSStyleRules_starting_style.html to cover this again.
Unfortunately the asserts in ServoStyleRuleMap.cpp no longer hold,
because the style attribute and other declarations are expected not to
show up there.
Differential Revision: https://phabricator.services.mozilla.com/D222856
I didn't put this behind a pref because it was a bit annoying to do with
the parser changes while keeping it fast, and because, at least nesting
wise, this is unlikely to cause compat issues.
There are some complexities for @scope, which I think I got right.
Fixed the tests not to depend on @scope necessarily per the discussion
in https://github.com/web-platform-tests/interop/issues/697.
Differential Revision: https://phabricator.services.mozilla.com/D222817
Parsing is disabled by the layout.css.margin-rules.enabled pref.
This isn't currently testable beyond a crashtest because the DOM interface for
margin rules isn't implemented yet.
Differential Revision: https://phabricator.services.mozilla.com/D187736
Lazily create the rule list since most style rules won't have child
rules.
Remaining failures in the cssom tests are tracked in other bugs.
Differential Revision: https://phabricator.services.mozilla.com/D180649
Lazily create the rule list since most style rules won't have child
rules.
Remaining failures in the cssom tests are tracked in other bugs.
Differential Revision: https://phabricator.services.mozilla.com/D180649
Implemented behind the new properties-and-values pref.
Support for the CSSPropertyRule WebIDL interface is also added in this
patch, because until it's added, any attempt to access the rule using
the CSSOM would crash the browser.
Depends on D178268
Differential Revision: https://phabricator.services.mozilla.com/D178270
Fixed always expecting stylesheets of import rules in ServoStyleRuleMap,
previously there was an assert and code expecting it to always exist,
which it does not always due to supports conditions of imports.
Differential Revision: https://phabricator.services.mozilla.com/D176897
Not yet hooked up to any rendering functionality.
The intention is for both the @font-palette-values at-rule and the font-palette property
to be behind the same pref being introduced here.
Differential Revision: https://phabricator.services.mozilla.com/D157953
Not yet hooked up to any rendering functionality.
The intention is for both the @font-palette-values at-rule and the font-palette property
to be behind the same pref being introduced here.
Differential Revision: https://phabricator.services.mozilla.com/D157953
Not yet hooked up to any rendering functionality.
The intention is for both the @font-palette-values at-rule and the font-palette property
to be behind the same pref being introduced here.
Differential Revision: https://phabricator.services.mozilla.com/D157953
Not yet hooked up to any rendering functionality.
The intention is for both the @font-palette-values at-rule and the font-palette property
to be behind the same pref being introduced here.
Differential Revision: https://phabricator.services.mozilla.com/D157953
Vincent Hilla