This patch adds the animation-timeline longhand property. For
shorthand, we will do that in the next patch.
This patch includes the aut-generated code in
devtools/shared/css/generated/properties-db.js, by `./mach devtools-css-db`.
Note:
1. we will use this property in Bug 1676791. For now, only make sure
we parse it and serialize it correctly.
2. The syntax of animation-timeline may be updated, based on the spec
issue: https://github.com/w3c/csswg-drafts/issues/6674.
However, it's not a big problem to update it later, so we still can
prototype this property based on the current version of spec.
Differential Revision: https://phabricator.services.mozilla.com/D126450
Add initial support for the color-scheme CSS property, allowing pages to
choose between light and dark system colors per-element, and such.
Things that are left to do so that this can be enabled by default:
* Dark system colors on Windows / Android / Standins.
* Dark Canvas/CanvasText/Link visited colors (which right now are set
via PreferenceSheet).
* Dark form controls in nsNativeBasicTheme.
* Processing the color-scheme meta tag to fill-in
Document::mColorSchemeBits.
But this seems like enough progress to be landable on its own.
Differential Revision: https://phabricator.services.mozilla.com/D120843
This changes font-family storage to reuse the rust types, removing a
bunch of code while at it. This allows us to, for example, use a single
static font family for -moz-bullet and clone it, rather than creating a
lot of expensive copies.
Differential Revision: https://phabricator.services.mozilla.com/D118011
This results in lots of new WPT test passes.
There were also a couple of WPT tests that turned out to be broken;
tab-size-inline-001 and -002 had errors in their reference files such
that they'd never pass anywhere. So those are fixed here.
Depends on D117331
Differential Revision: https://phabricator.services.mozilla.com/D117332
In this particular case the issue wouldn't end up in any sort of memory
corruption if we didn't safely crash, but these are quite tricky to
reason about, so it's better to avoid the reentrancy altogether if
possible.
I tried to convert the fuzzer test-case in a crashtest but failed (as
in, it didn't crash without the patch under the test harness).
Differential Revision: https://phabricator.services.mozilla.com/D115943
In this particular case the issue wouldn't end up in any sort of memory
corruption if we didn't safely crash, but these are quite tricky to
reason about, so it's better to avoid the reentrancy altogether if
possible.
I tried to convert the fuzzer test-case in a crashtest but failed (as
in, it didn't crash without the patch under the test harness).
Differential Revision: https://phabricator.services.mozilla.com/D115943
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
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
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
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
This parsing is hidden behind the pref layout.css.page-size.enabled.
It isn't ideal that we parse this as a property, but we can't treat it as a
descriptor because of compatibility issues with other browsers. There are also
outstanding spec issues related to how descriptors like page-size are cascaded,
and whether the !important specifier is valid or not.
Differential Revision: https://phabricator.services.mozilla.com/D103958
This makes -moz-outline-radius a no-op, but keep it for now.
If/when we make this the default in release, we can remove it.
Differential Revision: https://phabricator.services.mozilla.com/D104324
If we hit the canvas frame, and the root has a background but the body
doesn't, previously we were using the body style. Then
FindNonTransparentBackgroundFrame would return the document element
frame (with the right background), but FindBackgroundFor that failed.
Differential Revision: https://phabricator.services.mozilla.com/D103975
No behavior change, but the new place seems more appropriate.
StyleComputedUrl::ResolveImage is the only caller of ImageLoader::LoadImage,
and it calls it unconditionally modulo an special-case for documents.
Differential Revision: https://phabricator.services.mozilla.com/D103716
No behavior change, but the new place seems more appropriate.
StyleComputedUrl::ResolveImage is the only caller of ImageLoader::LoadImage,
and it calls it unconditionally modulo an special-case for documents.
Differential Revision: https://phabricator.services.mozilla.com/D103716
The only way that this can happen is if we get through the
ShouldTreatAsCompleteDueToSyncDecode check returning true in the case of
the image being errored.
https://hg.mozilla.org/integration/autoland/rev/645a4d6461ca was
supposed to deal with this, but my guess is that there is a slight race
condition in which the error status isn't there at the beginning, but is
there after the StartDecoding call.
It seems returning BAD_IMAGE rather than painting transparent if we hit
a broken image is a better thing to do than what we're doing now, and
should fix the intermittent issue.
Differential Revision: https://phabricator.services.mozilla.com/D101361
