Bug 1243549 fixed a race condition during SessionFile startup which
could cause calls to SessionFile.write to send messages to the worker
before it was initialized. The fix consisted in waiting until
initialization was complete before proceeding.
As it turns out, there are cases in which we send messages to the
worker without ever attempting to initialize it, so this wait ends up
causing a hang/shutdown.
This patch fixes the issue by making sure that any message sent to the
worker first initializes the worker if it hasn't been initialized
yet. Since initializing the worker requires us reading the session
store files to find out which one is valid, well, we do exactly that.
MozReview-Commit-ID: 1bOgCaF6ahM
While investigating bug 1243549, we encountered several instances of the following error message during each startup:
*************************
A coding exception was thrown and uncaught in a Task.
Full message: TypeError: this.Paths is null
Full stack: Agent.wipe@resource:///modules/sessionstore/SessionWorker.js:296:7
worker.dispatch@resource:///modules/sessionstore/SessionWorker.js:21:24
anonymous/AbstractWorker.prototype.handleMessage@resource://gre/modules/workers/PromiseWorker.js:122:16
@resource:///modules/sessionstore/SessionWorker.js:30:41
*************************
These messages can be explained as follows:
* If sanitization has failed during shutdown, it attempts again to
sanitize during startup. This happens more often than it used to,
because of 1/ startup bug fixes in bug 1089695; 2/ new shutdown bugs
most likely also added by or around bug 1089695.
* Sanitization during startup doesn't wait until Session Restore has
properly started to sanitize the session. So sanitization of Session
Restore file fails. This has probably always been the case, except
we never noticed.
* For some reason I do not understand, it attempts to sanitize several
times.
* I suspect that this can cause problems during startup, as
sanitization and Session Restore race to use/remove the files of
Session Restore.
This patch makes sure that SessionFile.wipe() waits until
initialization of SessionFile is complete before proceeding.
In a following patch, all DevTools moz.build files will use DevToolsModules to
install JS modules at a path that corresponds directly to their source tree
location. Here we rewrite all require and import calls to match the new
location that these files are installed to.
