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/
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.
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.
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.
Add-on developers should be actively encouraged to separate their "business logic" from their APIs by splitting them in a two or more different WebExtension packages: one "main" browser add-on and one or more API providers. Inclusion of native.js should ideally be limited to the latter, which would likely need to be modified less frequently and possibly be shared across multiple "main" add-ons. The longer approval times due to the compulsory AMO review that every native.js extension must undergo would probably be quite an incentive to embrace this separation model, but we should spell this message out in the documentation and within every each AMO review.