ExtensionParent.jsm cannot be loaded without a profile, as explained at
https://bugzilla.mozilla.org/show_bug.cgi?id=1761072#c5.
But ExtensionsBackgroundScriptStatusWatcher would try to (lazily) load
the module before a profile was ready, in order to subscribe to future
changes. To avoid loading this whole ExtensionParent.jsm module, I have
replaced the event propagation mechanism with observers.
Differential Revision: https://phabricator.services.mozilla.com/D142065
Additional changes needed to observe the "extension-worker-loaded" topics and notify the main process when the background
service worker script has been fully loaded (similarly to how we notify the main process when
the background page has been fully loaded).
Differential Revision: https://phabricator.services.mozilla.com/D124704
Additional changes needed to observe the "extension-worker-loaded" topics and notify the main process when the background
service worker script has been fully loaded (similarly to how we notify the main process when
the background page has been fully loaded).
Differential Revision: https://phabricator.services.mozilla.com/D124704
This patch introduces changes to parent/ext-backgroundPage.js and Extension's shutdown methods to make sure
that all service workers registered by an extension are unregistered when the extension is shutting down,
unless the application is also shutting down (in which case the registration is not unregistered because
for the already installed extenson the previously activeWorker is expected to be still active across browser
restarts).
These changes prevent also to hit the issue that D119532 was triggering when an extension was reloaded
and it does not need any of the changes to ContentPrincipal::AddonPolicy from D119531.
Differential Revision: https://phabricator.services.mozilla.com/D119903
- Adds the new about:config pref "extensions.backgroundServiceWorker.enabled" (currently defaults to false).
- Adds the background.service_worker property to the manifest JSON schema definition
- Locks background.service_worker manifest property behind the new preference
- Adds a new BackgroundWorker class to ext-backgroundPage.js (responsible for managing the background
service worker for the extension, e.g. make sure that the expected worker script is registered
as expected when the extension is starting up)
- Adds to the ServiceWorkerManager a new method to allow the WebExtension Framework to register the
background service worker without an existing extension page
- Allows the "moz-extension" schema in the dom/serviceworkers and dom/cache internals
Depends on D63697
Differential Revision: https://phabricator.services.mozilla.com/D60244
- Adds the new about:config pref "extensions.backgroundServiceWorker.enabled" (currently defaults to false).
- Adds the background.service_worker property to the manifest JSON schema definition
- Locks background.service_worker manifest property behind the new preference
- Adds a new BackgroundWorker class to ext-backgroundPage.js (responsible for managing the background
service worker for the extension, e.g. make sure that the expected worker script is registered
as expected when the extension is starting up)
- Adds to the ServiceWorkerManager a new method to allow the WebExtension Framework to register the
background service worker without an existing extension page
- Allows the "moz-extension" schema in the dom/serviceworkers and dom/cache internals
Depends on D63697
Differential Revision: https://phabricator.services.mozilla.com/D60244
Persistent listeners for onMessage and onConnect are special because they
don't have parent EventManagers, so we have a lot of custom code just to keep
track of which extensions have registered them during previous runs.
In this patch, I simplify all that logic to always assume that any extension
which sends messages from content scripts has those listeners setup properly.
The only observable difference is that some poorly written extensions which
were previously broken by delayed startup will now "work" by being started
earlier if a message from a content script arrives during browser startup.
Additionally, unconfuse two different meanings of the "startup" event.
Bonus, avoid some logspam during tests.
Differential Revision: https://phabricator.services.mozilla.com/D70955
