As per https://drafts.csswg.org/css-will-change/#will-change.
> If any non-initial value of a property would cause the element to
> generate a containing block for absolutely positioned elements,
> specifying that property in will-change must cause the element to
> generate a containing block for absolutely positioned elements.
But in this case the transform property wouldn't apply to the element so
there's no reason to create a stacking-context.
Differential Revision: https://phabricator.services.mozilla.com/D114121
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
It's the wrong pseudo-class name! Plus, it's not really needed, just
override the page styles temporarily.
Remove the pseudo-class, since it's its only remaining usage.
Differential Revision: https://phabricator.services.mozilla.com/D113374
So that sheets are properly marked as committed. The issue is that we
have this "committed" optimization, to avoid doing work if somebody adds
and removes an stylesheet without us flushing in the meantime:
https://searchfox.org/mozilla-central/rev/f018480dfed4fc583703a5770a6db9ab9dc0fb99/servo/components/style/stylesheet_set.rs#308-319
The "committed" bit is set when we consume the flusher (in each(..)).
However when we hit the cache, before this patch, we wouldn't consume
it, which means that we may fail to do some full rebuilds even though we
need them.
Fix it by making sure we call each() in that case.
We add a test (the test would show a red square before this patch, and a
lime square with the fix).
Differential Revision: https://phabricator.services.mozilla.com/D113206
This will allow detecting the system theme, which allows fixing some of
the blocked bugs.
Note that when using the system theme we will still match light or dark
appropriately, so this shouldn't change behavior just yet.
Differential Revision: https://phabricator.services.mozilla.com/D113516
We had about 9 gaps / unused bits. I moved the devtools ones at the end
because I think we should be able to remove them (but separate bug).
Differential Revision: https://phabricator.services.mozilla.com/D113365
We should just restore the state when seeing whitespace and an unknown
token like when we do when finding any other token a few lines below.
This is not an issue for most callers (it's only an issue for clamp())
because the other callers use either `parse_comma_separated()` (for
min/max), or `parse_nested_block()` (for parens / nested calc()).
Both of those functions restrict the input in such a way that
is_exhausted returns true (a few lines above) and thus we parse
successfully.
Differential Revision: https://phabricator.services.mozilla.com/D112681
https://drafts.csswg.org/css-images-4/#image-set-notation has:
> [...] it also specifies the image’s natural resolution, overriding any other
> source of data that might supply a natural resolution.
Astounding that there was literally no WPT for this at all. I added three: one
for backgrounds, one for list-style-image, and one for `content`. Cursor is not
handled on this patch because that one requires a fair amount of extra work.
Differential Revision: https://phabricator.services.mozilla.com/D112474
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
Safari does this. This reduces the runtime in the example linked from
comment 0 quite a lot (40ms on a local opt build, from ~130ms on a
release nightly build).
I added a pref because there's a slight chance of performance
regressions on pages that do not use attribute selectors, as we're now
doing more unconditional work per element (adding the attributes to the
bloom filter). But the trade-off should be worth it, I think.
Differential Revision: https://phabricator.services.mozilla.com/D111689
No behavior change, just cleanup. Actually seem this technically _adds_ some code even
though it's a cleanup, but that's mostly because of the wrapping of the
derive list. The resulting code is simpler (more in-line with our usual
things, so I think it's an improvement).
Differential Revision: https://phabricator.services.mozilla.com/D111551
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
There's no reason we can't just query LookAndFeel and we need to use
sSystemMetrics. In the past, LookAndFeel queries were not cached, but
this is no longer the case, so perf wise should be pretty equivalent.
Note that we don't need the NS_SUCCEEDED checks because the default
value from GetInt if the platform doesn't support it is 0 anyways.
Differential Revision: https://phabricator.services.mozilla.com/D110805
Similifies use of EventStates and ObjectType/FallbackType enums since most states they represented are no longer valid with the removal of NPAPI plugins. The state machine for (unsupported) plugin elements is now much simpler but still distinguishes between HTML fallbacks, fallbacks leading to a "BROKEN" state (e.g. failing to load the image the element refers to), and fallbacks that would simply lead the element to occupy an empty region. The last type of fallback is behind a pref "layout.use-plugin-fallback" and is disabled by default.
Simplifying the state machine allows us to clean up nsObjectLoadingContent. We also update many of the enums which refered to plugins, which would otherwise get confusing.
Differential Revision: https://phabricator.services.mozilla.com/D107158
