This is largely a straightforward find and replace of various methods, with the
unnecessary arguments removed and compiler errors fixed.
Differential Revision: https://phabricator.services.mozilla.com/D148532
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
#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
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
#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
This commit replaces IPCInternalResponse with three different structs:
ParentToParentInternalResponse, ParentToChildInternalResponse, and
ChildToParentInternalResponse. Doing this lets us convert runtime
checks into compile-time type checks and simplifies relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D131275
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
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
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
MainThreadWorkerControlRunnable::Cancel (indirectly) calls WorkerRun, which is
neither intuitive nor documented, but UpdateStateOpRunnable needs to account for
that to avoid a release assertion failure in ServiceWorkerOpArgs::AssertSanity.
Differential Revision: https://phabricator.services.mozilla.com/D61282
ServiceWorkerShutdownState encapsulates the shutdown progress for a particular
ServiceWorker. The shutdown process involves a "shutdown message" passing
multiple threads in both parent/content processes; we report a progress update
when it's known that a shutdown message has reached a particular thread. The
idea is that in the event of a shutdown timeout, ServiceWorkerShutdownBlocker
will be able to provide diagnostics for where shutdown processes are stalled.
Differential Revision: https://phabricator.services.mozilla.com/D60791
ServiceWorkerShutdownState encapsulates the shutdown progress for a particular
ServiceWorker. The shutdown process involves a "shutdown message" passing
multiple threads in both parent/content processes; we report a progress update
when it's known that a shutdown message has reached a particular thread. The
idea is that in the event of a shutdown timeout, ServiceWorkerShutdownBlocker
will be able to provide diagnostics for where shutdown processes are stalled.
Differential Revision: https://phabricator.services.mozilla.com/D60791
