mirror of
https://github.com/mozilla/gecko-dev.git
synced 2025-02-26 12:20:56 +00:00
162b9e42a8
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. Original Revision: https://phabricator.services.mozilla.com/D227446 Differential Revision: https://phabricator.services.mozilla.com/D228137