gecko-dev/dom/serviceworkers/ServiceWorkerOpPromise.h

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

52 lines
1.7 KiB
C
Raw Normal View History

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* 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/. */
#ifndef mozilla_dom_serviceworkeroppromise_h__
#define mozilla_dom_serviceworkeroppromise_h__
#include <utility>
#include "mozilla/MozPromise.h"
#include "mozilla/dom/SafeRefPtr.h"
#include "mozilla/dom/ServiceWorkerOpArgs.h"
namespace mozilla::dom {
class InternalResponse;
using SynthesizeResponseArgs =
std::tuple<SafeRefPtr<InternalResponse>, FetchEventRespondWithClosure,
FetchEventTimeStamps>;
using FetchEventRespondWithResult =
Variant<SynthesizeResponseArgs, ResetInterceptionArgs,
CancelInterceptionArgs>;
using FetchEventRespondWithPromise =
Bug 1693074 - Adding telemetry for evaluating the duration of fetch event dispatching and response synthesizing. r=dom-worker-reviewers,asuth This patch tries to record the fetch event dispatching time, the response's synthesizing time, and interception resetting time. Fetch event dispatching time is the time duration between interception starts, which is the time point of InterceptedHttpChannel::AsyncOpenInternal(), and the fetch handler starts. It includes the InterceptedHttpChannel setup time, ServiceWorker launch time, FetchEventOp propagation through IPC, a FetchEvent creation, initialization, and dispatching/scheduling on worker scope. Response synthesizing time is the time duration between the fetch handler finishes, which is the resolving/rejecting promise of respondWith(), to the finish of pumping the synthesized response to InterceptedHttpChannel, which is the time point of calling InterceptedHttpChannel::OnStopRequest(). It includes the response propagation through IPC, response header and body synthesis, and pumping synthesized response to the channel. Interception resetting time is the time duration between the fetch handler finishes and redirecting InterceptedHttpChannel to a normal HTTP channel. Since the fetch handler is executed on the process where the service worker spawned, the timestamps related to the fetch handler need to be get on that process. So this patch adds the FetchHandlerStart and FetchHandlerFinish on IPCFetchEventRespondWithResult related types to propagate the timestamps to the parent process. Depends on D118398 Differential Revision: https://phabricator.services.mozilla.com/D118399
2021-08-22 11:02:18 +00:00
MozPromise<FetchEventRespondWithResult, CancelInterceptionArgs, true>;
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
// The reject type int is arbitrary, since this promise will never get rejected.
// Unfortunately void is not supported as a reject type.
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
using FetchEventPreloadResponseAvailablePromise =
MozPromise<SafeRefPtr<InternalResponse>, int, true>;
using FetchEventPreloadResponseTimingPromise =
MozPromise<ResponseTiming, int, true>;
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
using FetchEventPreloadResponseEndPromise =
MozPromise<ResponseEndArgs, int, true>;
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
using ServiceWorkerOpPromise =
MozPromise<ServiceWorkerOpResult, nsresult, true>;
Bug 1662925 - Make SW fetch events properly queue. r=dom-workers-and-storage-reviewers,janv Excerpting some documentation I wrote up for an OVERVIEW.md for Service Workers for this exact use situation below. The basic situation of this patch is that we were trying to create the FetchEventOpProxyParent immediately before the managing PRemoteWorker instance existed, which isn't a thing we can do. Because FetchEvent ops are more complicated they require somewhat more unique handling, but it should have been unified with the PendingOp infrastructure and was not. The one notable thing going on actor-wise is that the request body (if present) requires special RemoteLazyInputStream serialization and this is something that can only be done once we have the RemoteWorkerParent. See https://phabricator.services.mozilla.com/D73173 and its commit message and my "Restating" blocks for more context. ### Threads and Proxies #### Main Thread ServiceWorkerManager's authoritative ServiceWorker state lives on the main thread in the parent process. This is due to a combination of legacy factors and that currently the nsHttpChannel AsyncOpen logic where navigation interception occurs must be on the main thread. #### IPDL Background Thread The IPDL Background Thread is the thread where PBackground parent actors are created. Because IPDL actors are explicitly tied to the thread they are created on and PBackground is the only top-level protocol created for use by DOM Workers, this thread is the natural home for book-keeping and authoritative state for APIs that are accessed via PBackground-managed protocols. For example, IndexedDB and other QuotaManager-managed storage APIs. The Remote Worker APIs are all PBackground managed and so all messages sent via the Remote Worker API need to be sent from the IPDL Background thread. #### Main Thread to IPDL Background Proxies There are 2 ways to get data from the main thread to the IPDL Background thread: either via direct runnable dispatch or via IPDL IPC. We use IPDL IPC (which has optimizations for same-process communication). The following interfaces exist exclusively to proxy requests from the ServiceWorkerManager on the main thread to the IPDL Background thread. - `PRemoteWorkerController` is a proxy wrapper around the `RemoteWorkerController` API exposed on the IPDL Background thread. - `PFetchEventOp` is paired with `PFetchEventOpProxy` managed by the above `PRemoteWorkerController`. `PFetchEventOp` gets the data to the IPDL Background thread from the main thread, then `PFetchEventOpProxy` gets the data down to the content process. ## Non-Fetch ServiceWorker events AKA ExtendableEvents How non-fetch events are dispatched to the serviceworker (including the IPC). Because ServiceWorkers are intended to be shutdown and restarted on demand and most event processing is asynchronous, there needs to be a way to track outstanding requests and for content logic to indicate when it is done processing requests. `ExtendableEvent`s are the mechanism for this. A method `waitUntil(promise)` adds promises to be track as long as the event is still "active". This straightforward lifecycle means that these events map well to our IPC async return value mechanism. This is used by `PRemoteWorker::ExecServiceWorkerOp`. ## Fetch events and FetchEvent.respondWith() `FetchEvent`s have a different lifecycle and dataflow than regular `ExtendableEvents`. They expose a `respondWith()` method that will eventually resolve with a fetch `Response` object that potentially needs to be propagated before the ExtendableEvent is no longer active. (The response will never be propagated after `waitUntil()` settles because every call to `respondWith()` implicitly calls `waitUntil()`.) From an IPC perspective, this means that `FetchEvent` instances need their own IPC actor rather than being able to depend on the async return value mechanism of IPDL. That's why `PFetchEventOpProxy` exists and is managed by `PRemoteWorker`. Differential Revision: https://phabricator.services.mozilla.com/D92021
2020-10-07 16:02:24 +00:00
using ServiceWorkerFetchEventOpPromise =
MozPromise<ServiceWorkerFetchEventOpResult, nsresult, true>;
} // namespace mozilla::dom
#endif // mozilla_dom_serviceworkeroppromise_h__