Specifically, remove the include of StructuredCloneHolder.h from
RefMessageBodyService.h, and that of WorkerRunnable.h from PromiseWorkerProxy.h
and add other required includes instead.
Differential Revision: https://phabricator.services.mozilla.com/D94764
This moves parts of IPCMessageUtils.h to two new header files and adapts
the include directives as necessary. The new header files are:
- EnumSerializer.h, which defines the templates for enum serializers
- IPCMessageUtilsSpecializations.h, which defines template specializations
of ParamTraits with extra dependencies (building upon both IPCMessageUtils.h
and EnumSerializer.h)
This should minimize the dependencies pulled in by every consumer of
IPCMessageUtils.h
Differential Revision: https://phabricator.services.mozilla.com/D94459
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
The Handle Fetch algorithm, steps 17 and 18, requires a soft update
when a fetch event is not dispatch for a non-subresource request.
Before this commit we added the requirement that the registration
be stale, which only applies to subresource requests.
Differential Revision: https://phabricator.services.mozilla.com/D96200
This supports one manifestparser expression per line in the 'skip-if',
'fail-if' and 'run-if' keys. As a side effect the:
skip-if = foo ||
bar
syntax is no longer supported. Instead it can be:
skip-if =
foo # bug 123
bar # bug 456
Differential Revision: https://phabricator.services.mozilla.com/D95927
This method only is async in order to allow callers to wait for a process switch
triggered by the call to `loadURI` to be finished before resolving. With
DocumentChannel, we should never trigger a process switch eagerly like this
again, so we don't need any of the async behaviour here anymore.
This part is largely mechanical changes to tests, removing the `await` calls on
`loadURI`, and a follow-up part will remove the actual async logic from
`BrowserTestUtils.loadURI`.
Differential Revision: https://phabricator.services.mozilla.com/D94641
Under parent intercept, we had both an nsIAsyncShutdownClient and a manual
observer notification used by ServiceWorkerManager for shutdown. (Under
child intercept, the observer notification used a different phase, but we no
longer support child intercept.) If the observer notification didn't fire
prior to the shutdown blocker, deadlock would result at shutdown.
This patch addresses the problem by changing us to only use the shutdown blocker
for profile-change-teardown, with it taking on the responsibility of calling
the relevant ServiceWorkerManager shutdown logic.
We do leave a finish shutdown observer notification in place. It's added
dynamically during shutdown (as long as we can get the observer service)
which I believe should allow the observer to run prior to the QuotaManager
profile-before-change-qm receiving its notification due to the reverse
observer notification. But that isn't required to avoid deadlocking.
As part of these changes, I also removed the configurable logic around shutdown
that existed to support child intercept. Note that this is not a comprehensive
cleanup, just a normalization of shutdown to require/assume parent intercept.
The most notable aspect of this change is explicitly bailing out of
ServiceWorkerManager initialization if we are not in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D94805
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This commit merges the TypedObject namespace into the WebAssembly namespace, and
only exposes the TypedObject definitions when the GC feature is enabled.
A future commit will remove the TypedObject definitions from the namespace, but we
still need the infrastructure from this commit for storing the TypedObject definitions
in private slots in the namespace.
Differential Revision: https://phabricator.services.mozilla.com/D92857
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
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