Hey,
For anyone who missed it, we had a meeting in Austin about how to move away from old-style bootstrapped add-ons. Specifically we're talking about things like bootstrap.js (which loads chrome-privileged JS code into the main process) and install.rdf (this is one of the things keeping us from dropping RDF support).
Keeping this support alive is also a burden in terms of code complexity and tests, mostly in the add-ons manager code.
We've successfully made this transition for third-party add-ons (AMO and Firefox both require WebExtensions), but we still have some Mozilla-published add-ons:
- Test Pilot
- System Add-ons[1]
- Shield studies
- Partners [2]
- Test automation
These still work because we make an exception for add-ons signed using an internal Mozilla key, as opposed to the key that AMO uses.
Per our meeting in Austin, we're deprecating bootstrap.js/install.rdf, and using WebExtensions wherever possible. Where not possible, use WebExtension Experiments[3].
The options are (in order of preference):
- contributing to the publicly-available WebExtension APIs
- using a bundled Experiment API / landing an internal-only WebExtension API in-tree
As with anything, there will be exceptions - for instance a system add-on that implements a feature may have the majority of its code in a bundled or internal-only API and use the manifest.json/background.js as they use install.rdf/bootstrap.js today, but it'd be better for the overall add-ons ecosystem to contribue to our publicly-available APIs.
Questions/suggestions welcome.
Thanks!
-Rob
1 - We ship several of these with Firefox in https://searchfox.org/mozilla-central/source/browser/extensions and we also use updates for one-off fixes (replacing the old Hotfix Add-on system.)
2 - There are also things like TorBrowser, which isn't technically published by Mozilla but still do use old-style add-ons.
3 - WebExtension Experiments are WE APIs that can be bundled in a XPI.