There's no reason we should need an scrollbar box to query the size of a
scrollbar. I plan to use this in the following patch to make the size of a
resizer not vary depending on whether the container has scrollbars or not,
which is what ultimately causes the reftest failure.
Differential Revision: https://phabricator.services.mozilla.com/D103302
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
We add two @-moz-document functions: `plain-text-document()`, matching the
obvious, and `unobservable-document()`, which matches a top-level document with
no opener. This is the equivalent check we do for automatic darkening of
`about:blank` here:
https://searchfox.org/mozilla-central/rev/014fe72eaba26dcf6082fb9bbaf208f97a38594e/layout/base/PresShell.cpp#5282
The former we don't need to use, but it's nice to let user stylesheets target
plaintext documents properly (rather than relying on extensions or what not).
Note that these are not content-observable.
Add two tests: One showing that we produce different rendering when on dark
mode, and one showing that we produce the same one from an iframe, regardless
of dark mode.
Depends on D101517
Differential Revision: https://phabricator.services.mozilla.com/D101518
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
This is based on the logic in ResponsiveImageSelector::SelectImage (just
simplified because there's no viewport-dependent widths here).
Differential Revision: https://phabricator.services.mozilla.com/D100698
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
This implements the basic image-set notation without the format()
function (for simplicity).
There's a remaining serialization issue (we should probably skip 1x
resolutions), but that's fine for now, I'll address this in a follow-up
when the feature is testable.
The intention is to do the image selection at computed value time
(keeping a selected index or such), but same, follow-up.
This also fixes an issue where the cors-mode for -moz-image-rect and
cross-fade() was getting ignored when parsing.
Differential Revision: https://phabricator.services.mozilla.com/D100640
This allows supporting image-set(), etc, and simplifies the bullet frame
code significantly, too thanks to two changes:
* Instead of manually managing the image request, use the CSS image
loader, with the `REQUEST_REQUIRES_REFLOW` flag, to handle image
loads correctly. This didn't exist when this code was initially
implemented, but we can nicely use it now.
* Instead of re-implementing another WebRender command-builder thing,
we can just reuse the nsImageRenderer code.
Differential Revision: https://phabricator.services.mozilla.com/D100774
These are never empty, and storing 4 elements inline seems worth it
given we also heap-allocate the array itself.
Depends on D100592
Differential Revision: https://phabricator.services.mozilla.com/D100593
Based on the spec, if the aspect-ratio property value is:
1) auto: we should always use content-box dimensions.
2) <ratio>: the aspect-ratio works with box sizing dimensions.
3) auto && <ratio>: we use content-box dimensions in all cases.
So we need an extra flag to address that we should use box-sizing or
always use content-box dimensions while computing the size in
ratio-dependent axis.
This also updates some wpts for non-replaced elements because we should
use content-box if aspect-ratio is 'auto && <ratio>'.
Differential Revision: https://phabricator.services.mozilla.com/D100072
This lifts a bunch of string conversions higher up the stack, but allows
us to make the servo code use utf-8 unconditionally, and seemed faster
in my benchmarking (see comment 0).
It should also make a bunch of attribute setters faster too (like
setting .cssText), now that we use UTF8String for them (we couldn't
because we couldn't specify different string types for the getter and
setters).
Differential Revision: https://phabricator.services.mozilla.com/D99590
We unshipped these a while ago and left the pref just for testing
purposes. But now all the reftests using it were conveniently migrated
to chrome:// tests, so we no longer need it.
Differential Revision: https://phabricator.services.mozilla.com/D56950
