In the future if we need to we can hook these up to telemetry (in fact it's not
hard, we just need to do that in Document::ReportUseCounters).
For now I want to start using them to record whether we might have a data URI.
Differential Revision: https://phabricator.services.mozilla.com/D258291
No behavior change, but this is simpler. I want to reuse the use
counters mechanism to fix this bug because it's a very trivial way of
asking questions about the parsed data and we need to plumb it through
the same places.
Differential Revision: https://phabricator.services.mozilla.com/D258290
Factor out the nsIconChannel symbolic lookup, and expose it to
nsImageRenderer to do the icon look-ups with the right CSS color.
Differential Revision: https://phabricator.services.mozilla.com/D252791
Eventually I want to simplify a lot of how the theming code deals with
overriding border / padding, and this helps with that.
Since bug 1765076 this isn't used anywhere, so I think simplifying this
is the right trade-off. Thunderbird also doesn't use it.
Differential Revision: https://phabricator.services.mozilla.com/D250314
In bug 1967507 I changed the timing of AnonymousContent stylesheet
loading in a way that it perturbed a css cache test because of
accessiblecaret.css
https://hg.mozilla.org/mozilla-central/rev/a6a294ae1d18
However that made me realize that accessiblecaret.css is loaded
virtually in all processes, and it should be using the same mechanism we
use for UA sheets, rather than using all the CSS loader machinery
in-content. Same goes for details.css.
Expand GlobalStyleSheetCache to allow UA and Author sheets, and allow
ShadowRoot to get built-in stylesheets appended.
This allows accessiblecaret.css and details.css not to be marked as
content-accessible.
We could do the same at the document level for plaintext.css and co, but
that seems a bit less common, so maybe fine.
Differential Revision: https://phabricator.services.mozilla.com/D250909
In bug 1967507 I changed the timing of AnonymousContent stylesheet
loading in a way that it perturbed a css cache test because of
accessiblecaret.css
https://hg.mozilla.org/mozilla-central/rev/a6a294ae1d18
However that made me realize that accessiblecaret.css is loaded
virtually in all processes, and it should be using the same mechanism we
use for UA sheets, rather than using all the CSS loader machinery
in-content. Same goes for details.css.
Expand GlobalStyleSheetCache to allow UA and Author sheets, and allow
ShadowRoot to get built-in stylesheets appended.
This allows accessiblecaret.css and details.css not to be marked as
content-accessible.
We could do the same at the document level for plaintext.css and co, but
that seems a bit less common, so maybe fine.
Differential Revision: https://phabricator.services.mozilla.com/D250909
Parse and serialize `view-transition-class: none | <custom-ident>+`.
This property will be used after we extend `<pt-name-selector>` to
`<pt-name-and-class-selector>` for named view transition pseudo-elements.
Will do this in Bug 1956646. Also, we will handle the class matching in
Bug 1964949.
Differential Revision: https://phabricator.services.mozilla.com/D249681
Making it conditional properly is kind of a pain right now and not
something I should land without review. Add a test so that we don't
forget to remove this or make it properly conditional when shipping it
to content.
Parse and serialize `view-transition-class: none | <custom-ident>+`.
This property will be used after we extend `<pt-name-selector>` to
`<pt-name-and-class-selector>` for named view transition pseudo-elements.
Will do this in Bug 1956646. Also, we will handle the class matching in
Bug 1964949.
Differential Revision: https://phabricator.services.mozilla.com/D249681
GTK4 paned widgets (see gtk4-demo) are only a thin line.
For now this does the windows thing as that's low-risk, which looks
basically the same as we have now for most themes.
We can make it look nicer in the future if needed.
Differential Revision: https://phabricator.services.mozilla.com/D249394
Gtk4 doesn't use different background colors for GtkColumnView (the
replacement for the treeview), so avoid computing one.
Our computation didn't have any guarantee of matching the fieldtext
foreground color.
This matches windows too. Remove unused -moz-eventreerow while at it.
Differential Revision: https://phabricator.services.mozilla.com/D249237
This reverts commit 8f772fe1b2.
Revert "Bug 1962978 - Use non-native listboxes on GTK. r=stransky,geckoview-reviewers,nika"
This reverts commit 751e7a3b2a.
GTK4 paned widgets (see gtk4-demo) are only a thin line.
For now this does the windows thing as that's low-risk, which looks
basically the same as we have now for most themes.
We can make it look nicer in the future if needed.
Differential Revision: https://phabricator.services.mozilla.com/D249394
Gtk4 doesn't use different background colors for GtkColumnView (the
replacement for the treeview), so avoid computing one.
Our computation didn't have any guarantee of matching the fieldtext
foreground color.
This matches windows too. Remove unused -moz-eventreerow while at it.
Differential Revision: https://phabricator.services.mozilla.com/D249237
Previous behaviour where we did not do compound matching is incorrect, but the
order invalidations are added bailed us out (Which makes it fragile).
Add a way to skip this "pull-up" behaviour for indexing selectors, since
element's poisition matters.
Differential Revision: https://phabricator.services.mozilla.com/D249431
When deep-cloning a stylesheet (like we do for devtools), we end up with
new (identical) LockedFontFaceRule object, but we'd fail to re-use it,
triggering new font loads. Since we don't cache failed loads, this
caused flashing and a temporary state where the used fonts were not what
this DevTools test expects.
Rejigger the code a little bit to push down the decision of whether to
reuse the FontFaceImpl object further down. That allows us to reuse the
FontFace object for the stylesheet caching / deep cloning use-case.
Differential Revision: https://phabricator.services.mozilla.com/D247704
Previously, we mapped left: anchor(left); to "Resolve anchor(left) with in
horizontal axis" - However, this doesn't work for two reasons:
1. `left: anchor(left)` and `right: anchor(left)` have to return 2 different
values to produce the identical result
2. We need side data for `left: anchor(inside)` and `right: anchor(outside)`
Differential Revision: https://phabricator.services.mozilla.com/D247663
Fixup for D241392: restrict `selectors::parser::PseudoElement` import
to Gecko, avoiding a compiler warning for Servo.
Fixup for D246780: move `QueryFontMetricsFlags` definition out of
Gecko-specific code, since its used in common APIs.
Differential Revision: https://phabricator.services.mozilla.com/D247757
This is a reland of de5756cfce68c56fa25ad8152b269dc2750dab99.
The earlier version of the change that was backed out for breaking the
build due to a broken merge resolution.
Differential Revision: https://phabricator.services.mozilla.com/D247142
We introduce `::-moz-snapshot-containing-block` pseudo-element to wrap
the view transition pseudo-element tree. This pseudo-element is only for
internal usage and cannot be accessed from outside.
Note that the related wpt,
`snapshot-containing-block-static.html`
`snapshot-containing-block-absolute.html`
are still failed because of Bug 1960755.
Also, add a test to check the snapshot containing block in the iframe,
and avoid hitting the issue of Bug 1960755.
There is no better way to verify that we do establish the fixed
positioning containing block, because it's unlikely to make the size of the
snapshot containing block be different from the viewport size on desktop
(note: this pseudo-element doesn't expose to the web), so I verified this
patch by changing the size of snapshot containing block manually in the UA
stylesheet, to see if it establish the fixed positioning containing block.
Differential Revision: https://phabricator.services.mozilla.com/D245648
