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
This patch doesn't change behavior; these APIs were already effectively
infallible, in the sense that it was impossible for them to return anything
other than NS_OK.
The actual API changes here are in xpcom/io/nsIPipe.idl and
xpcom/io/nsPipe3.cpp, and the rest of this patch is just updates to callsites,
removing code that handled failure-flavored return values from these functions.
(All of this removed code was already dead code, effectively.)
Differential Revision: https://phabricator.services.mozilla.com/D161947
Set the Content-Type to an empty string for an blob when the type was not
given. Ensure that the channel Content-Type is not overriden in the case
that it was previously set and the blob type is not valid.
Differential Revision: https://phabricator.services.mozilla.com/D147481
When a network load needs to be intercepted by ServiceWorker, we extract the Request from the InterceptedHttpChannel, and propagate the Request through FetchEvent.request.
However, some needed information is not extracted or is modified during the Request propagation, so getting the wrong result when using the Request to fetch resources in the ServiceWorker script.
Differential Revision: https://phabricator.services.mozilla.com/D145969
Set the Content-Type to an empty string for an blob when the type was not
given. Ensure that the channel Content-Type is not overriden in the case
that it was previously set and the blob type is not valid.
Depends on D147568
Differential Revision: https://phabricator.services.mozilla.com/D147481
This patch is more conservative for requests initiated by add-on and prefers
to send no Origin header instead of Origin: null.
Differential Revision: https://phabricator.services.mozilla.com/D147091
dom/console/Console.cpp:2899:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
dom/console/Console.cpp:2955:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return 0;
^
dom/fetch/FetchDriver.cpp:252:10: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return NS_OK;
^~~~~
Differential Revision: https://phabricator.services.mozilla.com/D126870
