632945 - Allow bootstrapped (restartless) add-ons to have XPCOM components with chrome.manifest

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Sean Leonard]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

This is an enhancement request to add support in Mozilla for restartless add-ons with both binary and JS XPCOM components, preferably based on chrome.manifest. It is related to "Catch 1" in Wladimir Palant's blog post: <http://adblockplus.org/blog/how-many-hacks-does-it-take-to-make-your-extension-install-without-a-restart>.

The main issues are:
- lifetime/lifecycle issues, especially around cached .getService() XPCOM components.
- loading and unloading a binary component safely (not safe to unload if there are outstanding reference counts)
- loading custom XPT interfaces (no obvious way to do this)

It is theoretically possible to do most of these (except, perhaps, XPT interfaces) with clever calls to nsIComponentRegistrar registerFactory and js-ctypes, but it will be very fragile and is at best undocumented.

Reproducible: Always




This bug should probably be dependent on bug 564667 (Allow bootstrapped add-ons to have chrome). While this bug could be implemented without bug 564667, it would be easier for everyone if chrome.manifest is simply parsed (or if there is a way for bootstrap.js to cause the manifest to be parsed at startup and "unparsed" at shutdown).

Comment 1

[Dave Townsend [:mossop]]

This isn't something we are going to work to support. JS XPCOM components can already be registered manually and we really want to deprecate binary component usage with js-ctypes picking up the slack.