This proposal aims to help complex and innovative extensions prosper also in the new Web-centric add-on ecosystem announced in https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
Add-on developers would be allowed to include, in an otherwise “pure” WebExtension package, a file similar to the bootstrap.js one currently supported by XPI add-ons, named “native.js” to better communicate its role. JavaScript code contained in this file would be subject to close scrutiny in AMO’s editorial policy. It would be executed on startup with chrome privileges, and it would have the ability (by importing ad hoc module or by injecting a global?) to interact with the WEAPI components through /runtime\.(connect|sendMessage|onMessage)/
IPC.
This would be a “natural” and losely coupled mechanism to isolate hacks and radical experiments from WEAPI code and to gradually port those bits into the new world, still making no promise to support anything (XUL, XPCOM, not even the SDK) in the long run.
We would retain the advantage of putting “new style” extensions in their own add-ons process, while the native.js scope would still live in the parent process and have access to whatever chrome-privileged JavaScript have access over the time (XPCOM today, browser.html and/or a Servo-provided API tomorrow?), with absolutely no guarantees of stability though (“Hack it at your own risk!”).
Packages containing a native.js file would raise a red flag both in AMO reviewer dashboard, to be examined more carefully, and in the user-facing installation/update permissions UI, asking for “browser super powers (can kidnap all your files into a cloud-based wormhole and ask for a ransom)”.
In this landscape we are still going to deprecate XUL (overlay) add-ons and the SDK’s require(“chrome”) within the planned timeline, providing “orphaned” developers with a strong incentive to migrate on WEAPI (especially for the front-end and for whatever functionality is already supported): nonetheless, they could resort to implement temporary hacks in native.js, not just for backward compatibility, but (especially) for experimenting with new concepts.
Anyway such hacks would need to go away, one by one, whenever WEAPI gets rich enough to replace them. To enforce this, we might even eventually introduce some mechanism causing calls into XPCOM APIs whose functionality is already surrogated by the WEAPI to throw when their caller is an add-on. However we should be very explicit about Mozilla’s freedom of removing legacy interfaces which don’t make sense anymore or hamper the browser’s evolution at any time, maybe with a 1-month courtesy notice and a replacement hint, because “native.js comes with no guarantees”. Alternatively, add-on developers who choose this risky path could just subscribe mozilla.dev.platform or an ad-hoc group (mozilla.dev.morgue?) to be alerted of such disruptive changes.
Update
In order to decentralize and distribute as much as possible the process of augmenting and refining the WebExtensions API, native.js should come with two key features:
- A meta-API to let add-ons declare, implement and export experimental additions to the core WebExtensions API. This enables add-ons developers to prototype their proposed new APIs and package them as "API provider" WebExtensions which may be used, tested and improved by other developers who share similar needs, reducing code and effort duplications and leading to a community-driven evolution path for the WebExtensions platform. The most valuable prototypes would be eventually adopted by Mozilla and included in the officially supported stable WebExtesions API.
- A solid dependency resolution system to promote modularization and reuse of API provider extensions, which should be installed and updated reliably and silently when required by another extension with no hassle for the end-users. This, of course, poses interesting questions about licenses and privacy policies, but nothing that we couldn't eventually settle.