mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-17 23:35:34 +00:00
Read-only Git mirror of the Mercurial gecko repositories at https://hg.mozilla.org. How to contribute: https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
c4e657f4da
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 |
||
|---|---|---|
| .cargo | ||
| .vscode | ||
| accessible | ||
| browser | ||
| build | ||
| caps | ||
| chrome | ||
| config | ||
| devtools | ||
| docs | ||
| docshell | ||
| dom | ||
| editor | ||
| extensions | ||
| gfx | ||
| gradle/wrapper | ||
| hal | ||
| image | ||
| intl | ||
| ipc | ||
| js | ||
| layout | ||
| media | ||
| memory | ||
| mfbt | ||
| mobile | ||
| modules | ||
| mozglue | ||
| netwerk | ||
| nsprpub | ||
| other-licenses | ||
| parser | ||
| python | ||
| remote | ||
| security | ||
| services | ||
| servo | ||
| startupcache | ||
| storage | ||
| taskcluster | ||
| testing | ||
| third_party | ||
| toolkit | ||
| tools | ||
| uriloader | ||
| view | ||
| widget | ||
| xpcom | ||
| xpfe/appshell | ||
| .arcconfig | ||
| .babel-eslint.rc.js | ||
| .clang-format | ||
| .clang-format-ignore | ||
| .cron.yml | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .flake8 | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .hg-annotate-ignore-revs | ||
| .hg-format-source | ||
| .hgignore | ||
| .hgtags | ||
| .lldbinit | ||
| .mailmap | ||
| .prettierignore | ||
| .prettierrc | ||
| .taskcluster.yml | ||
| .trackerignore | ||
| .yamllint | ||
| .ycm_extra_conf.py | ||
| aclocal.m4 | ||
| AUTHORS | ||
| build.gradle | ||
| Cargo.lock | ||
| Cargo.toml | ||
| client.mk | ||
| client.py | ||
| CLOBBER | ||
| configure.in | ||
| configure.py | ||
| GNUmakefile | ||
| gradle.properties | ||
| gradlew | ||
| gradlew.bat | ||
| LEGAL | ||
| LICENSE | ||
| mach | ||
| Makefile.in | ||
| moz.build | ||
| moz.configure | ||
| mozilla-config.h.in | ||
| old-configure.in | ||
| package-lock.json | ||
| package.json | ||
| README.txt | ||
| settings.gradle | ||
| substitute-local-geckoview.gradle | ||
| test.mozbuild | ||
An explanation of the Firefox Source Code Directory Structure and links to
project pages with documentation can be found at:
https://firefox-source-docs.mozilla.org/contributing/directory_structure.html
For information on how to build Firefox from the source code and create the patch see:
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
If you have a question about developing Firefox, and can't find the solution
on https://firefox-source-docs.mozilla.org/, you can try asking your question on Matrix at chat.mozilla.org in `Introduction` (https://chat.mozilla.org/#/room/#introduction:mozilla.org) channel.
Nightly development builds can be downloaded from:
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
- or -
https://www.mozilla.org/firefox/channel/desktop/#nightly
Keep in mind that nightly builds, which are used by Firefox developers for
testing, may be buggy.