158799bed4
Bug 1544232 changed it so ServiceWorker globals used a ClientInfo and Client Id created by the ServiceWorkerPrivate rather than creating a random client id. This allows the ServiceWorkerManager to reliably map a ServiceWorker Client Id back to the underlying ServiceWorker. The problem with this was that ClientManagerService is not okay with there being multiple ClientSources using the same id and it results in an IPC_FAIL. This was not a problem in desktop testing because under fission the potential race window is incredibly small for a ServiceWorker and its spawned successor to have a live ClientSource at the same time because the ClientSource will be torn down by the ClientManager WorkerRef on the transition to canceling and both SWs will be spawned in the same process. But on Android where there is no fission, SWs spawn randomly with no affinity and so a successor can be spawned on a different, more responsive process. The fix here is to regenerate the Client Id whenever we terminate the SW so we are prepared for the next time we spawn the SW. This patch adds an additional test case to browser_sw_lifetime_extension.js that is able to reproduce the crash case on desktop by artificially blocking the ServiceWorker thread with a monitor so that the ServiceWorker can't transition to Canceling until its successor has already been spawned. This reliably reproduces the bug (when the fix is not in place). This required adding some new test infrastructure to WorkerTestUtils. The new WorkerTestUtils methods provide 2 ways to hang the worker in a controlled fashion until an observer notification is notified on the main thread which use a shared helper class: 1. Use a monitor to completely block the thread until notified. This prevents control runnables from running and thereby prevents worker refs from being notified. 2. Acquire a ThreadSafeWorkerRef and hold it until notified. This lets the worker advance to Canceling but prevents progressing to Killing. I added the WorkerRef mechanism first but it wasn't sufficient, so I added the monitor mechanism, slightly generalizing the mechanism. A mechanism to generate an observer notification on the main thread is also added so that the successor ServiceWorker can notify the predecessor SW without us needing to involve JSActors or other means of running arbitrary JS in the process hosting the SWs. This does mean that when we are in non-fission mode we do need to limit the browser to a single process in order to ensure both workers are spawned in the same process. Differential Revision: https://phabricator.services.mozilla.com/D227446
39 lines
1.8 KiB
Plaintext
39 lines
1.8 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/. */
|
|
|
|
callback WorkerTestCallback = undefined ();
|
|
|
|
[Exposed=Worker, Pref="dom.workers.testing.enabled"]
|
|
namespace WorkerTestUtils {
|
|
[Throws]
|
|
unsigned long currentTimerNestingLevel();
|
|
[Throws]
|
|
boolean IsRunningInBackground();
|
|
|
|
// Mint a (ThreadSafe)StrongWorkerRef and hold it until we see an observer
|
|
// notification with the given string topic on the main thread. The
|
|
// StrongWorkerRef will prevent the worker from moving from the Canceling to
|
|
// the Killing state and thereby prevent it from shutting down.
|
|
[Throws]
|
|
undefined holdStrongWorkerRefUntilMainThreadObserverNotified(UTF8String topic);
|
|
|
|
// Create a monitor that blocks the worker entirely until we see an observer
|
|
// notification with the given string topic on the main thread. This is a
|
|
// much more drastic variant of
|
|
// holdStrongWorkerRefUntilMainThreadObserverNotified for when the goal is to
|
|
// avoid letting WorkerRefs be notified. A callback should be passed to be
|
|
// synchronously invoked once the observer has been registered in order to
|
|
// communicate that the test can move forward.
|
|
[Throws]
|
|
undefined blockUntilMainThreadObserverNotified(UTF8String topic,
|
|
WorkerTestCallback whenObserving);
|
|
|
|
// Dispatch a runnable to the main thread to notify the observer service with
|
|
// the given topic. This is primarily intended for use with
|
|
// `holdStrongWorkerRefUntilMainThreadObserverNotified` but might be useful in
|
|
// other situations to cut down on test boilerplate.
|
|
[Throws]
|
|
undefined notifyObserverOnMainThread(UTF8String topic);
|
|
};
|