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 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 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 first patch to remove response timing from ResponseEndArgs, and also remove the timing recording from OnResponseEnd for PFetch and ServiceWorker NavigationPreload.
Differential Revision: https://phabricator.services.mozilla.com/D167936
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 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 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 first patch to remove response timing from ResponseEndArgs, and also remove the timing recording from OnResponseEnd for PFetch and ServiceWorker NavigationPreload.
Differential Revision: https://phabricator.services.mozilla.com/D167936
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
In the previous implementation, FetchEvent.preloadResponse is resolved when the response fetching finishes.
However, ServiceWorker responding letency could be increased since waiting for preloadResponse finishes.
The patch resolves FetchEvent.preloadResponse earlier when the response is available.
The basic idea is to resolve the preload response when FetchInstance::OnResponseAvailableInternal() is called.
Then propagating the response from the parent process main thread to the content process worker thread. This is achieved by IPC PFetchEventOp::Send/RecvPreloadResponse -> PFetchEventOpProxy::Send/RecvPreloadResponse.
Since we can only get the response's ResourceTiming when FetchInstance::OnResponseEnd() is called. This patch introduces a new IPC method to propagate the ResourceTiming information from the parent process main thread to the content process worker thread.
PFetchEventOp::Send/RecvPreloadResponseEnd -> PFetchEventOpProxy->Send/RecvPreloadResponseEnd.
The tricky of this patch is we must extend the life cycle of FetchEventOp object if preloadResponse is set into FetchEvent.
That because ServiceWorker could resolve FetchEvent.respondWith() by using FetchEvent.preloadResponse.
In that case, FetchEventOp will get into a finish state and try to call FetchEventOpProxyChild::Senddelete with the operation result.
However, the ResponseEnd could not be called at the moment, and we need to wait for the corresponding timing information and its end reason.
To extend the life cycle of FetchEventOp, this patch cached the operation result while we get FetchEventOp::Callback is called. Then call FetchEventOpProxyChile::Senddelete() in FetchEventOpProxyChild::RecvPreloadResponseEnd() to close IPC. Or Senddelete() will be called while ActorDestroy() caused by shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D145338
Currently using the pricinpal of InternalRequest to create the channel for NavigationPreload.
However, it is not a correct principal and makes NavigationPreload stop with channel security checking.
Instead of using the principal of InternalRequest, this patch uses the loadingPrincipal of InterceptedHttpChannel to create the channel.
Differential Revision: https://phabricator.services.mozilla.com/D137594
Currently using the pricinpal of InternalRequest to create the channel for NavigationPreload.
However, it is not a correct principal and makes NavigationPreload stop with channel security checking.
Instead of using the principal of InternalRequest, this patch uses the loadingPrincipal of InterceptedHttpChannel to create the channel.
Differential Revision: https://phabricator.services.mozilla.com/D137594
Currently using the pricinpal of InternalRequest to create the channel for NavigationPreload.
However, it is not a correct principal and makes NavigationPreload stop with channel security checking.
Instead of using the principal of InternalRequest, this patch uses the loadingPrincipal of InterceptedHttpChannel to create the channel.
Differential Revision: https://phabricator.services.mozilla.com/D137594
