It's a 1:1 mapping for the origin that we cache in the
StyleSheetContents, so use that.
PreloadHashKey only cares about author loads, within a document, so
doesn't really need to deal with user / user-agent ones.
Differential Revision: https://phabricator.services.mozilla.com/D304400
We don't need it:
* For built-in sheets (ContentParent etc) the original URI is the same.
* For Document / nsStyleSheetService / LinkStyle, the original URI is
what you want to avoid registering / loading the same URI multiple
times.
Differential Revision: https://phabricator.services.mozilla.com/D269423
Make SetURIs be the source of truth for referrer info and principal too.
This allows us to remove redundant members.
Pull the URI and such out of StyleSheetInfo, since we are sharing
StyleSheetInfo across stylesheets with different base URIs and such now
(for inline stylesheets), and we need to keep track of the "right" base
URI for when we eventually clone them.
There's one part of the change here which is a bit scary, which is the
principal shenanigans. However I don't think it's problematic since we
already are using the URLExtraData for CSS parsing and subresource
loads, which doesn't have that mutation. In particular, we only use
StyleSheet::Principal from Loader::LoadChildSheet. So we can implement
what the spec actually says (an origin-clean flag).
Differential Revision: https://phabricator.services.mozilla.com/D269210
Make SetURIs be the source of truth for referrer info and principal too.
This allows us to remove redundant members.
Pull the URI and such out of StyleSheetInfo, since we are sharing
StyleSheetInfo across stylesheets with different base URIs and such now
(for inline stylesheets), and we need to keep track of the "right" base
URI for when we eventually clone them.
There's one part of the change here which is a bit scary, which is the
principal shenanigans. However I don't think it's problematic since we
already are using the URLExtraData for CSS parsing and subresource
loads, which doesn't have that mutation. In particular, we only use
StyleSheet::Principal from Loader::LoadChildSheet. So we can implement
what the spec actually says (an origin-clean flag).
Differential Revision: https://phabricator.services.mozilla.com/D269210
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
This disarms a footgun in the FreezableMapping::Freeze API, which was
causing read-only mappings in the global stylesheet cache to fail. These
failures caused content processes to re-load the style sheets,
increasing memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D240928
This disarms a footgun in the FreezableMapping::Freeze API, which was
causing read-only mappings in the global stylesheet cache to fail. These
failures caused content processes to re-load the style sheets,
increasing memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D240928
While much of this is simply converting code (and removing extraneous
`size` parameters), toolkit/xre/GeckoArgs.{h,cpp} has some significant
changes to support sending read-only handles (which is all we need!).
Differential Revision: https://phabricator.services.mozilla.com/D236750
While much of this is simply converting code (and removing extraneous
`size` parameters), toolkit/xre/GeckoArgs.{h,cpp} has some significant
changes to support sending read-only handles (which is all we need!).
Differential Revision: https://phabricator.services.mozilla.com/D236750
This makes sure that the URLExtraData contains the right referrer info,
and thus that mChromeRulesEnabled is correct.
Remove some useless includes while at it.
Differential Revision: https://phabricator.services.mozilla.com/D193047
This changes -moz-bool-pref from @supports to @media, bringing various
improvements:
* @media (-moz-bool-pref) properly reacts to dynamic changes.
* We no longer need to parse chrome:// stylesheets in the main thread
(-moz-bool-pref was the only thing that forced us to do that).
This makes privileged and non-privileged stylesheets more similar.
Differential Revision: https://phabricator.services.mozilla.com/D191196
These days, after bug 1853323, about:PreferenceStyleSheet is basically
just an empty sheet for most users. For the ones that isn't, it's either
slightly or completely broken (see below).
If we were to implement this today, we'd do it with privileged env()
variables or media queries, and add a bunch of tests for different
combinations, but I don't think it's worth the effort:
* There's no UI for any of these prefs.
* There are no tests for any of these prefs.
* browser.display.focus_ring_or_anything is not great, it's better
replaced by browser.display.show_focus_rings, which actually makes
the :focus-visible pseudo-class work. Otherwise the native controls
may show no rings even though this pref is set.
* for browser.display.focus_ring_style = 0, the color used
(-moz-mac-focusring) is not implemented in any non-macOS platform.
* The ::-moz-focus-inner rules are completely useless nowadays, because
::-moz-focus-inner only works on the windows native theme (which
isn't used on content).
* The focus colors are not color-scheme aware.
So given those, and that if you want the specific current behavior,
these are trivially implementable as a web extension (by using a user
stylesheet), I think we should just remove this code altogether.
Differential Revision: https://phabricator.services.mozilla.com/D190464
This is weirdly placed in the colors dialog, and adds a global selector
to the UA sheet for no great reason.
This sub-setting doesn't really make a lot of sense. We don't let you
force underlines in any way, so any site CSS will override it (unlike
colors, where you can actually override the site).
Just move this to the UA sheet properly.
Differential Revision: https://phabricator.services.mozilla.com/D188326
HasBoxFFI and HasArcFFI aren't great, see bug 1831242 as for examples of
why.
HasArcFFI requires a bit more care, but HasBoxFFI doesn't give us much
benefit. Instead use the same type in the FFI boundary.
Differential Revision: https://phabricator.services.mozilla.com/D177252
I don't think there's ever a way these should differ.
Got some include hell from removing ReferrerInfo.h from Document.h but
hopefully should be straight-forward to review.
Depends on D173154
Differential Revision: https://phabricator.services.mozilla.com/D173155
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
This is useful for the following parts, as UniqueFileHandle is a cross-platform
type which can also be used to support transferring HANDLEs between processes.
This change requires fairly sweeping changes to existing callsites, which
previously did not require owning access to the handle types when transferring.
For the most part these changes were straightforward, but manual.
Differential Revision: https://phabricator.services.mozilla.com/D126564
Remove the need to post a runnable to coalesce them (we still coalesce
theme changes because those do non-trivial work).
What can go on is that on cold load we load the font list async, and
that goes through this code via a faked font.internaluseonly.changed
pref change, which stores a reframe change hint in
mChangeHintForPrefChange.
If the page flushes after this code runs, but before the next refresh
driver tick, we will be just wasting work. So instead do the
RebuildAllStyleData call synchronously. It just schedules a flush and
posts a hint, so it doesn't do the work right there, but makes the next
flush do the work as needed, so it should be faster and also more
correct.
Also improve handling of preference sheet prefs and such to avoid more
wasted work when we go through this code, as the assumption their
handling was doing was that it gets called infrequently, but it's not
the case due to the font list updates.
Differential Revision: https://phabricator.services.mozilla.com/D123103
We expose these via CSS system colors, so this way we don't need to
rebuild the preference sheet when the link color is different.
Differential Revision: https://phabricator.services.mozilla.com/D120677
We still panic in a debug build, so that developers can notice when they
need to add a new static atom after modifying UA sheets.
We also add telemetry to note when this happens, add an app note to a
crash report, in case any crash later on occurs, and re-up the existing,
expired shared memory sheet telemetry probes so we can look at them
again.
Differential Revision: https://phabricator.services.mozilla.com/D73188
Emilio Cobos Álvarez