With the checkin of bug 300731 the extensions.ini file is deleted on each upgrade. The EM's checkForMismatches only loads the extension datasource during a x.x+ upgrade and this will recreate the extensions.ini file early in the startup process. Now that this has changed extensions are not loaded without restarting once after upgrading nightly builds. I haven't looked deeply into what would be the best way to fix this but the following in checkForMismatches worked for me. > var extensionsList = getFile(KEY_PROFILEDIR, [FILE_EXTENSION_MANIFEST]); >- if (!extensionsList.exists()) >- needsRestart = true; >+ if (!extensionsList.exists()) { >+ this._updateExtensionsManifest(true); >+ needsRestart = true; >+ } I won't have time until this evening to look into this further

After checking this out in a debug build I think this is a better way to go. Farther along the EM wants a restart due to recreating the extensions.ini at that point and has already hit the limit.

Comment on attachment 190404 [details] [diff] [review] patch I'm not sure I understand why this patch is correct... if we deleted the extensions.ini we almost certainly *do* want to force a restart.

There are a couple of places where a restart is requested. This is from checkForMismatches where with this patch if there are incompatible items a restart is requested and without it a restart is also requested if the extensions.ini does not exist... note that the code does not attempt to create the extensions.ini at this time. A restart is also requested in start and as the idl for start states * @returns true if the application has rewritten the extensions.ini file * and needs to restart to register components/chrome etc, * false otherwise So, it requests a restart in checkForMismatches and then when it requests a restart in start it has already max'd out the number of restarts permitted.

Comment on attachment 190404 [details] [diff] [review] patch ok, makes sense

Fixed on trunk for 1.8b4