This patch include some additional changes to the diagnostic assert to be able to include:
- the error name for the E10SUtils call failure
- the file name and line number that originated the error
The change itself does not include a new automated test, but I did verify locally the new expected crash message:
- by temporarily a js error and a Components.Exception to be thrown while running one of the existing tests (dom/workers/test/xpcshell/test_remoteworker_launch_new_process.js).
- and also temporarily forcing the failure while the method is being called in both the parent and child processes.
Differential Revision: https://phabricator.services.mozilla.com/D96598
This patch makes cranelift and ion exclusive of each other: enabling
cranelift on a platform will effectively disable Ion on that platform.
Specifically there's a change at the pref/switch level that does not
go terribly deep:
- the new about:config option is javascript.options.wasm_optimizingjit,
the old wasm_cranelift and wasm_ionjit are no more
- new values of X in --wasm-compiler=X in the js shell are 'optimizing'
and 'baseline+optimizing', the old values 'cranelift', 'ion',
'baseline+ion' and 'baseline+optimizing' are still accepted but only
when ion or cranelift is available
- we keep the separate prefs internally in the code for ion and cranelift
but if ENABLE_WASM_CRANELIFT is defined then we never set the ion
pref to true, and if it is not defined then we never set the cranelift
pref to true
The trickiest changes are in testWasm.cpp and in the JIT compiler option
processing in jsapi.cpp.
People who will suffer as a result of this are those who are working
on ports of cranelift to new platforms in Firefox. As of now we have
no such work going on.
In the longer term the exclusive-or situation can be alleviated by a
switch that lets cranelift override ion when cranelift is present and
the switch is on. Patches welcome.
Differential Revision: https://phabricator.services.mozilla.com/D96059
Before this commit RemoteWorkerService asserted during shutdown that
it was initialized correctly. Unfortunately, initialization can fail,
so this commit takes that into account.
Differential Revision: https://phabricator.services.mozilla.com/D94824
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
The issue here is that we access the WorkerPrivate::mJSContext while dispatching
a micro task runnable to micro task queue. While we are running the worker
script, this should be safe. However, it's possible that process the micro tasks
while clearing the main event queue. And, in this case, the worker is about to
shutdown so the mJSContext has already set to a nullptr.
GetCurrentWorkerThreadJSContext() returns WorkerPrivete::mJSContext. It's set at
the beginning of the WorkerPrivate::DoRunLoop() (which is got from
CycleCollectedJSContext::mJSContext), and it is set to a nullptr at the end of
WorkerPrivate::DoRunLoop(). Thus, the result of
CycleCollectedJSContext::Context() is the same as the result of
GetCurrentWorkerThreadJSContext() before either of the JSContext pointer is set
to a nullptr. So, we should be safe to change the use of the getter function to
Context() here.
Differential Revision: https://phabricator.services.mozilla.com/D87615
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
- Using MonitorAutoLock/Monitor::Wait with the timeout argument instead of the eternal Wait() in CrashIfHangingRunnable::DispatchAndWait
- Augment the runnable to use an boolean to track whether or not it has effectively "resolved" with an answer so that we only write to mMsg exactly once. While the call to Wait(timeout) indicates what happened with its CVStatus return, it's necessary to make sure that WorkerRun/Cancel check this value before potentially mutating mMsg in the event they actually do run after the timed wait has given up.
- Add crash information, if the worker is a Chrome worker and in case add the executed script URL
Differential Revision: https://phabricator.services.mozilla.com/D92204
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
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
This commit adds the boilerplate machinery for the function-references proposal. The
interesting piece is that the GC proposal is moved to require the function-references
proposal to be enabled.
The configuration machinery for features is refactored in this commit to avoid passing
6 different booleans around as parameters to functions.
* A FeatureArgs struct is added with values for all 'feature' configuration options
- A feature is defined as an option that affects validation or semantics
- Essentially everything besides 'debug', 'mode', 'tier'
* All feature configuration responsibility is removed from CompilerEnvironment
* ModuleEnvironment is modified to accept a FeatureArgs in addition to a
CompilerEnvironment
- The CompilerEnvironment field may eventually be removed, as it's not needed
within function validation, and is only used by the compilers later
Differential Revision: https://phabricator.services.mozilla.com/D89857
The intermittent failure seems to be easily reproducible locally by running the marionette test multiple times in a row
using `mach marionette-test --run-until-failure ...`.
Explicitly waiting for the serviceworker.txt file to be created in the Firefox profile
before restarting the instance seems to be enough to allow the test to complete successfully
with --run-until-profile, and so the reason behind the intermittent failure is very likely
due to the Firefox instances quitting before the registered workers are being actually being
stored in the profile.
This patch does add a small change to the marionette test that makes sure that the test case
is going to restart the Firefox instance after the serviceworker.txt file has been created
in that Firefox profile.
Depends on D90189
Differential Revision: https://phabricator.services.mozilla.com/D90369
The name `AUTO_PROFILER_MARKER_TEXT` is more consistent with the equivalent non-`AUTO` macro, and similarly arguments have been re-ordered to be the same, i.e.: Name, category&options, text.
The different macros with different argument sets can now be collapsed into one macro, and the optional arguments (timing, inner window id, backtrace) can easily be added to the `MarkerOptions` where needed.
As a bonus, a specific start time can optionally be provided at construction time.
Differential Revision: https://phabricator.services.mozilla.com/D89588
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
This adds the preference, JS shell option, and {ContextOptions,CompileOptions} fields,
but the value isn't read and the code always acts as it's set to true.
Differential Revision: https://phabricator.services.mozilla.com/D88922
