gecko-dev/dom/serviceworkers/ServiceWorkerOpArgs.ipdlh

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

192 строки
5.0 KiB
Plaintext
Исходник Обычный вид История

/* 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 ClientIPCTypes;
include DOMTypes;
include FetchTypes;
include "mozilla/dom/ServiceWorkerIPCUtils.h";
using mozilla::dom::ServiceWorkerState from "mozilla/dom/ServiceWorkerBinding.h";
using mozilla::TimeStamp from "mozilla/TimeStamp.h";
namespace mozilla {
namespace dom {
/**
* ServiceWorkerOpArgs
*/
struct ServiceWorkerCheckScriptEvaluationOpArgs {};
struct ServiceWorkerUpdateStateOpArgs {
ServiceWorkerState state;
};
struct ServiceWorkerTerminateWorkerOpArgs {
uint32_t shutdownStateId;
};
struct ServiceWorkerLifeCycleEventOpArgs {
nsString eventName;
};
// Possibly need to differentiate an empty array from the absence of an array.
union OptionalPushData {
void_t;
uint8_t[];
};
struct ServiceWorkerPushEventOpArgs {
nsString messageId;
OptionalPushData data;
};
struct ServiceWorkerPushSubscriptionChangeEventOpArgs {};
struct ServiceWorkerNotificationEventOpArgs {
nsString eventName;
nsString id;
nsString title;
nsString dir;
nsString lang;
nsString body;
nsString tag;
nsString icon;
nsString data;
nsString behavior;
nsString scope;
uint32_t disableOpenClickDelay;
};
Bug 1728327 - Introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method. r=asuth This patch includes a set of changes to the ServiceWorker internals to introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method, to be used by the WebExtensions internals to request an active background service worker to be spawned (if it is not yet) in response to a WebExtension API event. The new method gets as parameters: - the scope URL for the extension background service worker to spawn - WebExtensions API namespace and API event name which we are going to spawn an active worker for and return a promise which would be: - rejected if the worker could not be spawned - resolved to a boolean if the worker was spawned successfully (or already running) The value of the boolean value resolved is meant to represent if the worker did actually have any listener subscribed for the given WebExtensions API event listener (which the WebExtensions internals may then use to decide if it is worth to send that event to be handled by the worker script or not). In this patch the ExtensionBrowser::HasWakeupEventListener used to determine if an WebExtensions API event was subscribed syncronously when the worker was being loaded is not implemented yet and it is always returning false (a proposed implementation for that method is going to be added in a separate patch part of this same bugzilla issue). A unit test for the new proposed nsIServiceWorkerManager method is also part of a separate patch (attached to this bugzilla issue as the child revision for this one). Differential Revision: https://phabricator.services.mozilla.com/D130756
2021-12-15 21:29:36 +03:00
struct ServiceWorkerExtensionAPIEventOpArgs {
// WebExtensions API namespace and event names, for a list of the API namespaces
// and related API event names refer to the API JSONSchema files in-tree:
//
// https://searchfox.org/mozilla-central/search?q=&path=extensions%2Fschemas%2F*.json
nsString apiNamespace;
nsString apiEventName;
};
struct ServiceWorkerMessageEventOpArgs {
ClientInfoAndState clientInfoAndState;
ClonedOrErrorMessageData clonedData;
};
struct ServiceWorkerFetchEventOpArgsCommon {
nsCString workerScriptSpec;
IPCInternalRequest internalRequest;
nsString clientId;
nsString resultingClientId;
bool isNonSubresourceRequest;
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 23:24:27 +03:00
// Is navigation preload enabled for this fetch? If true, if some
// preloadResponse was not already provided in this structure, then it's
// expected that a PreloadResponse message will eventually be sent.
bool preloadNavigation;
// Failure injection helper; non-NS_OK values indicate that the event, instead
// of dispatching should instead return a `CancelInterceptionArgs` response
// with this nsresult. This value originates from
// `nsIServiceWorkerInfo::testingInjectCancellation`.
nsresult testingInjectCancellation;
};
struct ParentToParentServiceWorkerFetchEventOpArgs {
ServiceWorkerFetchEventOpArgsCommon common;
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 22:40:47 +03:00
ParentToParentInternalResponse? preloadResponse;
ResponseTiming? preloadResponseTiming;
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 22:40:47 +03:00
ResponseEndArgs? preloadResponseEndArgs;
};
struct ParentToChildServiceWorkerFetchEventOpArgs {
ServiceWorkerFetchEventOpArgsCommon common;
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 22:40:47 +03:00
ParentToChildInternalResponse? preloadResponse;
ResponseTiming? preloadResponseTiming;
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 22:40:47 +03:00
ResponseEndArgs? preloadResponseEndArgs;
};
union ServiceWorkerOpArgs {
ServiceWorkerCheckScriptEvaluationOpArgs;
ServiceWorkerUpdateStateOpArgs;
ServiceWorkerTerminateWorkerOpArgs;
ServiceWorkerLifeCycleEventOpArgs;
ServiceWorkerPushEventOpArgs;
ServiceWorkerPushSubscriptionChangeEventOpArgs;
ServiceWorkerNotificationEventOpArgs;
ServiceWorkerMessageEventOpArgs;
Bug 1728327 - Introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method. r=asuth This patch includes a set of changes to the ServiceWorker internals to introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method, to be used by the WebExtensions internals to request an active background service worker to be spawned (if it is not yet) in response to a WebExtension API event. The new method gets as parameters: - the scope URL for the extension background service worker to spawn - WebExtensions API namespace and API event name which we are going to spawn an active worker for and return a promise which would be: - rejected if the worker could not be spawned - resolved to a boolean if the worker was spawned successfully (or already running) The value of the boolean value resolved is meant to represent if the worker did actually have any listener subscribed for the given WebExtensions API event listener (which the WebExtensions internals may then use to decide if it is worth to send that event to be handled by the worker script or not). In this patch the ExtensionBrowser::HasWakeupEventListener used to determine if an WebExtensions API event was subscribed syncronously when the worker was being loaded is not implemented yet and it is always returning false (a proposed implementation for that method is going to be added in a separate patch part of this same bugzilla issue). A unit test for the new proposed nsIServiceWorkerManager method is also part of a separate patch (attached to this bugzilla issue as the child revision for this one). Differential Revision: https://phabricator.services.mozilla.com/D130756
2021-12-15 21:29:36 +03:00
ServiceWorkerExtensionAPIEventOpArgs;
ParentToChildServiceWorkerFetchEventOpArgs;
};
/**
* IPCFetchEventRespondWithResult
*/
struct FetchEventRespondWithClosure {
nsCString respondWithScriptSpec;
uint32_t respondWithLineNumber;
uint32_t respondWithColumnNumber;
};
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 14:02:18 +03:00
struct FetchEventTimeStamps {
TimeStamp fetchHandlerStart;
TimeStamp fetchHandlerFinish;
};
struct ChildToParentSynthesizeResponseArgs {
ChildToParentInternalResponse internalResponse;
FetchEventRespondWithClosure closure;
FetchEventTimeStamps timeStamps;
};
struct ParentToParentSynthesizeResponseArgs {
ParentToParentInternalResponse internalResponse;
FetchEventRespondWithClosure closure;
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 14:02:18 +03:00
FetchEventTimeStamps timeStamps;
};
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 14:02:18 +03:00
struct ResetInterceptionArgs {
FetchEventTimeStamps timeStamps;
};
struct CancelInterceptionArgs {
nsresult status;
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 14:02:18 +03:00
FetchEventTimeStamps timeStamps;
};
union ChildToParentFetchEventRespondWithResult {
ChildToParentSynthesizeResponseArgs;
ResetInterceptionArgs;
CancelInterceptionArgs;
};
union ParentToParentFetchEventRespondWithResult {
ParentToParentSynthesizeResponseArgs;
ResetInterceptionArgs;
CancelInterceptionArgs;
};
/**
* ServiceWorkerOpResult
*/
struct ServiceWorkerCheckScriptEvaluationOpResult {
bool workerScriptExecutedSuccessfully;
bool fetchHandlerWasAdded;
};
struct ServiceWorkerFetchEventOpResult {
nsresult rv;
};
Bug 1728327 - Introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method. r=asuth This patch includes a set of changes to the ServiceWorker internals to introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method, to be used by the WebExtensions internals to request an active background service worker to be spawned (if it is not yet) in response to a WebExtension API event. The new method gets as parameters: - the scope URL for the extension background service worker to spawn - WebExtensions API namespace and API event name which we are going to spawn an active worker for and return a promise which would be: - rejected if the worker could not be spawned - resolved to a boolean if the worker was spawned successfully (or already running) The value of the boolean value resolved is meant to represent if the worker did actually have any listener subscribed for the given WebExtensions API event listener (which the WebExtensions internals may then use to decide if it is worth to send that event to be handled by the worker script or not). In this patch the ExtensionBrowser::HasWakeupEventListener used to determine if an WebExtensions API event was subscribed syncronously when the worker was being loaded is not implemented yet and it is always returning false (a proposed implementation for that method is going to be added in a separate patch part of this same bugzilla issue). A unit test for the new proposed nsIServiceWorkerManager method is also part of a separate patch (attached to this bugzilla issue as the child revision for this one). Differential Revision: https://phabricator.services.mozilla.com/D130756
2021-12-15 21:29:36 +03:00
struct ServiceWorkerExtensionAPIEventOpResult {
bool extensionAPIEventListenerWasAdded;
};
union ServiceWorkerOpResult {
nsresult;
ServiceWorkerCheckScriptEvaluationOpResult;
ServiceWorkerFetchEventOpResult;
Bug 1728327 - Introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method. r=asuth This patch includes a set of changes to the ServiceWorker internals to introduce a new nsIServiceWorkerManager.wakeForExtensionAPIEvent method, to be used by the WebExtensions internals to request an active background service worker to be spawned (if it is not yet) in response to a WebExtension API event. The new method gets as parameters: - the scope URL for the extension background service worker to spawn - WebExtensions API namespace and API event name which we are going to spawn an active worker for and return a promise which would be: - rejected if the worker could not be spawned - resolved to a boolean if the worker was spawned successfully (or already running) The value of the boolean value resolved is meant to represent if the worker did actually have any listener subscribed for the given WebExtensions API event listener (which the WebExtensions internals may then use to decide if it is worth to send that event to be handled by the worker script or not). In this patch the ExtensionBrowser::HasWakeupEventListener used to determine if an WebExtensions API event was subscribed syncronously when the worker was being loaded is not implemented yet and it is always returning false (a proposed implementation for that method is going to be added in a separate patch part of this same bugzilla issue). A unit test for the new proposed nsIServiceWorkerManager method is also part of a separate patch (attached to this bugzilla issue as the child revision for this one). Differential Revision: https://phabricator.services.mozilla.com/D130756
2021-12-15 21:29:36 +03:00
ServiceWorkerExtensionAPIEventOpResult;
};
} // namespace dom
} // namespace mozilla