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
MOZ_RUNINIT => initialized at runtime
MOZ_CONSTINIT => initialized at compile time
MOZ_GLOBINIT => initialized either at runtime or compile time, depending on template parameter, macro parameter etc
This annotation is only understood by our clang-tidy plugin. It has no
effect on regular compilation.
Differential Revision: https://phabricator.services.mozilla.com/D223341
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
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 third patch for reporting the response timing for PFetch.
This patch adds the needed IPC PFetch/Send/RecvOnReportPerformanceTiming to propagate the response timing from the parent process main thread to the content process worker thread.
Depends on D167937
Differential Revision: https://phabricator.services.mozilla.com/D167938
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 third patch for reporting the response timing for PFetch.
This patch adds the needed IPC PFetch/Send/RecvOnReportPerformanceTiming to propagate the response timing from the parent process main thread to the content process worker thread.
Depends on D167937
Differential Revision: https://phabricator.services.mozilla.com/D167938
And use nsID::ToProvidedString(...) method when suitable.
This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D167606
And use nsID::ToProvidedString(...) method when suitable.
This naturally fixes a memory leak in dom/fetch/FetchParent.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D167606
