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
All present uses of the call-site arguments to MozPromise's methods
supply static strings. However, this is nowhere enforced. Do so.
Additionally, since this is the third or fourth time the present author
alone has personally implemented such an enforcement mechanism, create a
helper class to simplify doing so.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D207462
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
[[ https://searchfox.org/mozilla-central/rev/da1e39f50ef43145623938141c970437b226da9e/dom/fetch/FetchService.cpp#591 | fetch() in Workers when network is offline would returns a NetworkError response]], but this error response is not propagated through PFetch.
Before FetchInstance is created in the parent process, any errors should be propagated to the Worker.
This patch modifies the FetchService::NetworkErrorResponse() method to propagate the error to worker when PFetch is used.
To propagate the error, additional parameter FetchArgs is needed for FetchService::NetworkErrorResponse().
Since the propagation would only work when the FetchArgs is a WorkerFetchArgs, it gets a default parameter with UnknownArgs for other cases.
Here using UnknownArgs since it can meet errors while generating other types FetchArgs.
Differential Revision: https://phabricator.services.mozilla.com/D186125
[[ https://searchfox.org/mozilla-central/rev/da1e39f50ef43145623938141c970437b226da9e/dom/fetch/FetchService.cpp#591 | fetch() in Workers when network is offline would returns a NetworkError response]], but this error response is not propagated through PFetch.
Before FetchInstance is created in the parent process, any errors should be propagated to the Worker.
This patch modifies the FetchService::NetworkErrorResponse() method to propagate the error to worker when PFetch is used.
To propagate the error, additional parameter FetchArgs is needed for FetchService::NetworkErrorResponse().
Since the propagation would only work when the FetchArgs is a WorkerFetchArgs, it gets a default parameter with UnknownArgs for other cases.
Here using UnknownArgs since it can meet errors while generating other types FetchArgs.
Differential Revision: https://phabricator.services.mozilla.com/D186125
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.
This patch is the first part to propagte the worker's associated BrowsingContextID to the parent process through PFetch.
Differential Revision: https://phabricator.services.mozilla.com/D174249
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.
This patch is the first part to propagte the worker's associated BrowsingContextID to the parent process through PFetch.
Differential Revision: https://phabricator.services.mozilla.com/D174249
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 fourth patch for reporting the preload response timing for ServiceWorker NavigationPreload.
This patch adds the needed IPCs PFetchEventOp and PFetchEventOpProxy to propagate the preload response timing from the parent process main thread to the content process worker thread.
Since navigation preload is an asynchronous action, corresponding promises for asynchronous propagation are also created in FetchService, FetchEventOpChild, FetchEventOpProxyChild, and FetchEventOp.
Depends on D167938
Differential Revision: https://phabricator.services.mozilla.com/D167939
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 fourth patch for reporting the preload response timing for ServiceWorker NavigationPreload.
This patch adds the needed IPCs PFetchEventOp and PFetchEventOpProxy to propagate the preload response timing from the parent process main thread to the content process worker thread.
Since navigation preload is an asynchronous action, corresponding promises for asynchronous propagation are also created in FetchService, FetchEventOpChild, FetchEventOpProxyChild, and FetchEventOp.
Depends on D167938
Differential Revision: https://phabricator.services.mozilla.com/D167939
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
