The referrer info is more directly what we want (what triggered this
load).
I could add this information for non-http channels, but I think it's
probably not worth it. This is useful because it's thread-safe, which
allows me to support off-main-thread parsing of stylesheets that contain
SRI metadata.
It also simplifies the API and avoids getting URIs around in non-error
code paths.
Differential Revision: https://phabricator.services.mozilla.com/D238612
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Depends on D223380
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Depends on D223380
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Differential Revision: https://phabricator.services.mozilla.com/D223936
We need to propagate the isOn3PCBExceptionList flag from the nsILoadInfo
to workers so that the requests from workers can have the flag to exempt
third-party cookie blocking. We will also tackle the fetch request in
the worker scope in the patch.
Differential Revision: https://phabricator.services.mozilla.com/D223936
This allows code with Chrome priviledges to use the fetch API
to specify a triggering principal instead of needing to use
XMLHttpRequest.
The triggeringPrincipal is only used when the fetch principal
is already the systemPrincipal.
Differential Revision: https://phabricator.services.mozilla.com/D213418
According to step 15 of [1], request’s destination is used in an
implementation-defined manner to set the internal priority but we
currently always use the preferences corresponding to the adjustments
of the global fetch API.
This patch handle destinations corresponding to CSP directives
"font-src", "script-src", "style-src", "img-src" and "media-src" [2]
specially by respectively using the adjustment preferences named
"link-preload-font", "link-preload-script", "link-preload-style"
"images" and a new preference "media".
Special handling of these destinations is motivated by the fact that
they are mentioned explicitly on [3]. For "media" we choose preferences
following the suggestions from that article (i.e. media is low
priority). However, for now we don't change the default value and make
sure fetchpriority=high/low preserves the invariants tested by
fetchpriority-adjustments.html
[1] https://fetch.spec.whatwg.org/#concept-fetch
[2] https://fetch.spec.whatwg.org/#destination-table
[3] https://web.dev/articles/fetch-priority?hl=en#browser_priority_and_fetchpriority
Differential Revision: https://phabricator.services.mozilla.com/D208467
According to step 15 of [1], request’s destination is used in an
implementation-defined manner to set the internal priority but we
currently always use the preferences corresponding to the adjustments
of the global fetch API.
This patch handle destinations corresponding to CSP directives
"font-src", "script-src", "style-src", "img-src" and "media-src" [2]
specially by respectively using the adjustment preferences named
"link-preload-font", "link-preload-script", "link-preload-style"
"images" and a new preference "media".
Special handling of these destinations is motivated by the fact that
they are mentioned explicitly on [3]. For "media" we choose preferences
following the suggestions from that article (i.e. media is low
priority). However, for now we don't change the default value and make
sure fetchpriority=high/low preserves the invariants tested by
fetchpriority-adjustments.html
[1] https://fetch.spec.whatwg.org/#concept-fetch
[2] https://fetch.spec.whatwg.org/#destination-table
[3] https://web.dev/articles/fetch-priority?hl=en#browser_priority_and_fetchpriority
Differential Revision: https://phabricator.services.mozilla.com/D208467
We propergate the isInThirdPartyContext bit from the workerPrivate to
the fetchDrvier. So, we can set the bit for the channel that loads the
fetch request for workers.
Differential Revision: https://phabricator.services.mozilla.com/D207139
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
This is to add basic fetch priority support. It introduces preference of
fetch priority adjustment as per to recent discussions. We need to refine the
fetchpriority mapping taking into account of destination, which will be
addressed in Bug 1881040.
In addition, this changes the relervant prefs type to atomic type to accommodate
the access of the prefs off the main thread in the worker case.
Differential Revision: https://phabricator.services.mozilla.com/D200778
