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
This avoids potential issues where multiple OnDataAvailable callbacks or
similar could theoretically be called concurrently on different
StreamTransportService threads when targeting the STS - these cases will
now target a TaskQueue on the STS instead, structurally ensuring serial
execution.
Differential Revision: https://phabricator.services.mozilla.com/D179984
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor watches channels and NetEvents, stack traces are only caught in the content process.
That means PFetch should notify the netmonitor about the stack trace of the fetch at the proper moment.
In original fetch steps, FetchDriver would notify the netmonitor the fetch stack trace at
https://searchfox.org/mozilla-central/rev/cdddec7fd690700efa4d6b48532cf70155e0386b/dom/fetch/FetchDriver.cpp#834
When PFetch is enabled, PFetch needs also to propagate this notification back to the content process.
Depends on D174442
Differential Revision: https://phabricator.services.mozilla.com/D174443
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.
In P1, https://phabricator.services.mozilla.com/D174249, we propagate the BrowsingContext ID through PFetch.
In this patch, we need to save it in channel's LoadInfo for netmonitor.
In order not to confuse with nsILoadInfo's BrowsingContextID, we create a new attribute WorkerAssociatedBrowsingContextID in nsILoadInfo.
Depends on D174249
Differential Revision: https://phabricator.services.mozilla.com/D174441
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor watches channels and NetEvents, stack traces are only caught in the content process.
That means PFetch should notify the netmonitor about the stack trace of the fetch at the proper moment.
In original fetch steps, FetchDriver would notify the netmonitor the fetch stack trace at
https://searchfox.org/mozilla-central/rev/cdddec7fd690700efa4d6b48532cf70155e0386b/dom/fetch/FetchDriver.cpp#834
When PFetch is enabled, PFetch needs also to propagate this notification back to the content process.
Depends on D174442
Differential Revision: https://phabricator.services.mozilla.com/D174443
After PFetch is enabled, fetch() call in workers will not create a channel in the content process anymore.
Although netmonitor also watches the channels in the parent process, the created channel still loses the BrowsingContext information for netmonitor to connect the network event and the channel.
In P1, https://phabricator.services.mozilla.com/D174249, we propagate the BrowsingContext ID through PFetch.
In this patch, we need to save it in channel's LoadInfo for netmonitor.
In order not to confuse with nsILoadInfo's BrowsingContextID, we create a new attribute WorkerAssociatedBrowsingContextID in nsILoadInfo.
Depends on D174249
Differential Revision: https://phabricator.services.mozilla.com/D174441
Since Bug 1802086, we strip authentication headers when redirected to a cross-origin page. However, the api ReferrerInfo::IsCrossOriginRequest used for determining whether a request is cross-origin cannot be used as it compares the triggering principal's uri with the redirected channel's uri. This comparison might sometimes yield to false positives.
For e.g consider the following scenario:
1. Load `https://example.org/` and send the following fetch request from browser console
```
fetch("https://test.com/some_location", {
"headers": {
"Authorization": "Token foo"
}
});
```
2. Server responds with a redirect to https://test.com/another_location
In the above scenario, the api ReferrerInfo::IsCrossOriginRequest will yield the above request as cross origin since the triggering principal uri here is example.com. Hence, this will be treated as cross-origin redirect resulting in removal of auth headers.
Thus ReferrerInfo::IsCrossOriginRequest has been replaced with nsScriptSecurityManager::CheckSameOriginURI where we directly compare the origins for the two requests.
Differential Revision: https://phabricator.services.mozilla.com/D170868
Response Timing should be reported before the body stream completing.
In the original implementation, the response timing is recorded when OnResponseEnd is called, but it is too late. Response timing could not be ready when response.text() or response.blob() resolves the promise.
This is the second patch to add a new interface OnReportPerformanceTiming() on FetchDriverObserver, so FetchDriver could control when to report the response timing.
The patch gives an empty implementation in FetchDriverObserver for MainThreadFetchResolver and WorkerFetchResolver. And FetchInstace overrides the method for PFetch and ServiceWorker NavigationPreload.
Depends on D167936
Differential Revision: https://phabricator.services.mozilla.com/D167937
Response Timing should be reported before the body stream completing.
In the original implementation, the response timing is recorded when OnResponseEnd is called, but it is too late. Response timing could not be ready when response.text() or response.blob() resolves the promise.
This is the second patch to add a new interface OnReportPerformanceTiming() on FetchDriverObserver, so FetchDriver could control when to report the response timing.
The patch gives an empty implementation in FetchDriverObserver for MainThreadFetchResolver and WorkerFetchResolver. And FetchInstace overrides the method for PFetch and ServiceWorker NavigationPreload.
Depends on D167936
Differential Revision: https://phabricator.services.mozilla.com/D167937
