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
And apply the auto-fix from the linter. Note that we exclude RefPtr from
the check as it plays badly with our CanRunScriptChecker's linter.
We also explicitly silent warning for loops on nsTObserverArray, as their
iterator is designed to support invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D293497
Motivation: MakeAndAddRef forces us to store the result in a refcounted
pointer, which is a nice safety/strictness improvement. Also, migrating lets
us reduce the number of manual 'new' invocations, which reduces our audit
surface for memory-allocation/lifetime issues.
Differential Revision: https://phabricator.services.mozilla.com/D299010
It's a no-op due to ORB in practice now, but added a test for both the
redirect case and data: uris.
Remove SheetLoadData::mLoaderPrincipal since now we don't access it off
main thread anymore.
Differential Revision: https://phabricator.services.mozilla.com/D269492
The network predictor used the HTTP cache as a database to learn browsing
patterns and make speculative DNS prefetches, TCP preconnects, and resource
prefetches. While this provided performance benefits for repeat visits to
frequently-accessed sites, it came with significant costs: I/O on every page
load, CPU overhead for prediction algorithms, memory for caching learned
patterns, and substantial IPC complexity with six message types coordinating
predictions between processes.
A large part of the functionality the predictor was meant to improve is now
available to webdevelopers. HTTP 103 Early Hints allow servers to explicitly
specify resources to preload while generating the response.
And Speculation Rules API will enable content authors to declaratively specify
prefetch/prerender behavior based on their knowledge of site structure and user
intent, providing immediate accuracy without a learning period.
The network.predictor.enable-hover-on-ssl preference is retained as it controls
simpler hover-triggered speculative connections that don't require the
predictor's learning system. This removal simplifies the codebase while
steering users toward more accurate, standards-based optimization mechanisms.
The one feature of the predictor which was never used was learning websites
that are opened soon after startup. There was no action taken based on this
info, and we could already predict this info based on the history database.
Differential Revision: https://phabricator.services.mozilla.com/D276437
The network predictor used the HTTP cache as a database to learn browsing
patterns and make speculative DNS prefetches, TCP preconnects, and resource
prefetches. While this provided performance benefits for repeat visits to
frequently-accessed sites, it came with significant costs: I/O on every page
load, CPU overhead for prediction algorithms, memory for caching learned
patterns, and substantial IPC complexity with six message types coordinating
predictions between processes.
A large part of the functionality the predictor was meant to improve is now
available to webdevelopers. HTTP 103 Early Hints allow servers to explicitly
specify resources to preload while generating the response.
And Speculation Rules API will enable content authors to declaratively specify
prefetch/prerender behavior based on their knowledge of site structure and user
intent, providing immediate accuracy without a learning period.
The network.predictor.enable-hover-on-ssl preference is retained as it controls
simpler hover-triggered speculative connections that don't require the
predictor's learning system. This removal simplifies the codebase while
steering users toward more accurate, standards-based optimization mechanisms.
The one feature of the predictor which was never used was learning websites
that are opened soon after startup. There was no action taken based on this
info, and we could already predict this info based on the history database.
Differential Revision: https://phabricator.services.mozilla.com/D276437
Adding a stylesheet in a data document (either programmatically or via
something like a UA widget like comment 3) seems perfectly expected.
Differential Revision: https://phabricator.services.mozilla.com/D275355
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
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
It is replaced by a standard-conforming cast to (void) which is
understood the same by the compiler.
In some cases this could be replaced by `[[maybe_unused]]` but for
expression whose value is ignored, this requires storing to a temporary
variable first, so not going that way.
One notable change is that marking an object of type already_AddRefed as
unused used to implicitly leak memory. This is now made explicit.
Most of the heavy lifting was done through:
$ git grep -l '\<Unused\> <<' | xargs sed -i -e 's/Unused << /(void)/g'
$ git grep -l mozilla/Unused.h | xargs sed -i -e '/mozilla\/Unused.h/ d'
Differential Revision: https://phabricator.services.mozilla.com/D268706
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
I checked every `HttpBaseChannel::SetupReplacementChannel` call (including calls to overrides) and we always create a copy of the existing loadinfo, usually with `CloneLoadInfoForRedirect`, except for TRR, it just calls `TRRLoadInfo::Clone`.
Differential Revision: https://phabricator.services.mozilla.com/D255316
This reverts commit efd9a5ba48.
Revert "Bug 1968644 - Part 9: Add more tests for loads triggered by tracking scripts. r=valentin,anti-tracking-reviewers,emz"
This reverts commit 7d5c3e1c1c.
Revert "Bug 1968644 - Part 8: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for WebSocket requests. r=valentin,necko-reviewers"
This reverts commit 53a783a51e.
Revert "Bug 1968644 - Part 7: Add tests. r=necko-reviewers,anti-tracking-reviewers,emz,valentin"
This reverts commit e52f034955.
Revert "Bug 1968644 - Part 6: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags during channel creation. r=necko-reviewers,kershaw"
This reverts commit f564c21b37.
Revert "Bug 1968644 - Part 5: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for CSS loads. r=emilio"
This reverts commit 8a8fd7bacc.
Revert "Bug 1968644 - Part 4: Populate triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for loads. r=smaug,necko-reviewers"
This reverts commit 7b3ba3b668.
Revert "Bug 1968644 - Part 3: Populate the triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags for fetch requests. r=valentin,smaug"
This reverts commit 08f090244f.
Revert "Bug 1968644 - Part 2: Intorduce the ClassificationFlags to nsIClassifiedChannel.idl. r=dimi,necko-reviewers,valentin"
This reverts commit b8c01cd77c.
Revert "Bug 1968644 - Part 1: Introduce triggeringFirstPartyClassificationFlags and triggeringThirdPartyClassificationFlags to LoadInfo. r=necko-reviewers,kershaw"
This reverts commit a7619a72b4.
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 prevents browser_css_cache from spuriously failing on ASAN builds
after the last patch, since now creating the accessiblecaret doesn't
force a flush (and thus might not force accessiblecaret.css to be
parsed).
Daniel Holbert