gecko-dev/dom/serviceworkers/PFetchEventOp.ipdl

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

36 lines
954 B
Plaintext
Raw Permalink Normal View History

/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
include protocol PRemoteWorkerController;
include ServiceWorkerOpArgs;
Bug 1577346 - P4 IPC implementation for FetchEvent.preloadResponse. r=dom-worker-reviewers,ytausky This patch implements the IPC for propagating the preload response from the parent process' main thread to the content process' worker thread. The following is the complicated propagation path. FetchEventOpChild(Parent process main thread) => FetchEventOpParent(Parent process background thread) => FetchEventOpProxyParent(Parent process background thread) => FetchEventOpProxyChild(content process worker launch thread) => ServiceWorker(content process worker thread) However, since preload response fetching is an asynchronous behavior, the preload response can be ready at any time point during the fetch event dispatching. This patch also handles different situations. Basically, it can be separated into the following stages. 1. Preload response is ready when the fetch event dispatching is in the parent process main thread, which means the fetch event is pending as a ServiceWorkerPrivateImpl::PendingFetchEvent. Details in PendingFetchEvent and FetchEventOpChild 2. Preload response is ready when the fetch event dispatching is in the parent process background thread, which means fetch event is still waiting for worker launching. Details in FetchEventOpParent and FetchEventOpProxyParent. 3. Preload response is ready when constructing the fetch event. Details in FetchEventOpProxyChild and ServiceWorkerOp::FetchEventOp. Depends on D126244 Differential Revision: https://phabricator.services.mozilla.com/D122821
2021-11-09 20:24:27 +00:00
include FetchTypes;
namespace mozilla {
namespace dom {
[ManualDealloc]
protocol PFetchEventOp {
manager PRemoteWorkerController;
Bug 1577346 - P4 IPC implementation for FetchEvent.preloadResponse. r=dom-worker-reviewers,ytausky This patch implements the IPC for propagating the preload response from the parent process' main thread to the content process' worker thread. The following is the complicated propagation path. FetchEventOpChild(Parent process main thread) => FetchEventOpParent(Parent process background thread) => FetchEventOpProxyParent(Parent process background thread) => FetchEventOpProxyChild(content process worker launch thread) => ServiceWorker(content process worker thread) However, since preload response fetching is an asynchronous behavior, the preload response can be ready at any time point during the fetch event dispatching. This patch also handles different situations. Basically, it can be separated into the following stages. 1. Preload response is ready when the fetch event dispatching is in the parent process main thread, which means the fetch event is pending as a ServiceWorkerPrivateImpl::PendingFetchEvent. Details in PendingFetchEvent and FetchEventOpChild 2. Preload response is ready when the fetch event dispatching is in the parent process background thread, which means fetch event is still waiting for worker launching. Details in FetchEventOpParent and FetchEventOpProxyParent. 3. Preload response is ready when constructing the fetch event. Details in FetchEventOpProxyChild and ServiceWorkerOp::FetchEventOp. Depends on D126244 Differential Revision: https://phabricator.services.mozilla.com/D122821
2021-11-09 20:24:27 +00:00
parent:
Bug 1765777 - Resolve FetchEvent.preloadResponse when the response is available not the response end. r=dom-worker-reviewers,jesup. 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
2022-05-11 19:40:47 +00:00
async PreloadResponse(ParentToParentInternalResponse aResponse);
async PreloadResponseTiming(ResponseTiming aTiming);
Bug 1765777 - Resolve FetchEvent.preloadResponse when the response is available not the response end. r=dom-worker-reviewers,jesup. 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
2022-05-11 19:40:47 +00:00
async PreloadResponseEnd(ResponseEndArgs aArgs);
Bug 1577346 - P4 IPC implementation for FetchEvent.preloadResponse. r=dom-worker-reviewers,ytausky This patch implements the IPC for propagating the preload response from the parent process' main thread to the content process' worker thread. The following is the complicated propagation path. FetchEventOpChild(Parent process main thread) => FetchEventOpParent(Parent process background thread) => FetchEventOpProxyParent(Parent process background thread) => FetchEventOpProxyChild(content process worker launch thread) => ServiceWorker(content process worker thread) However, since preload response fetching is an asynchronous behavior, the preload response can be ready at any time point during the fetch event dispatching. This patch also handles different situations. Basically, it can be separated into the following stages. 1. Preload response is ready when the fetch event dispatching is in the parent process main thread, which means the fetch event is pending as a ServiceWorkerPrivateImpl::PendingFetchEvent. Details in PendingFetchEvent and FetchEventOpChild 2. Preload response is ready when the fetch event dispatching is in the parent process background thread, which means fetch event is still waiting for worker launching. Details in FetchEventOpParent and FetchEventOpProxyParent. 3. Preload response is ready when constructing the fetch event. Details in FetchEventOpProxyChild and ServiceWorkerOp::FetchEventOp. Depends on D126244 Differential Revision: https://phabricator.services.mozilla.com/D122821
2021-11-09 20:24:27 +00:00
child:
async AsyncLog(nsCString aScriptSpec, uint32_t aLineNumber,
uint32_t aColumnNumber, nsCString aMessageName,
nsString[] aParams);
async RespondWith(ParentToParentFetchEventRespondWithResult aResult);
async __delete__(ServiceWorkerFetchEventOpResult aResult);
};
} // namespace dom
} // namespace mozilla