Multiple breaking changes are coming for components in extensions

Are you an extension or application developer? Have you written any XPCOM components, JS, binary or otherwise? If not you can probably ignore the rest of this post, unless you are interested anyway.

If you do then you might be interested to hear that your components are probably going to break in an upcoming Firefox nightly, maybe as early as next week. I’m going to blog specific examples on the changes you need to make once we have better documentation up and builds to test against, for now it is just important for you to know that the changes are coming.

Changing XPCOM component registration

One of the things we are doing is changing how XPCOM components are registered. Previously during registration we would load all binary and JS component files and call them asking them to register themselves. If you used XPCOMUtils.jsm then some of that ugliness will have been hidden from you. The future though will be registration using manifest files, similar to how chrome is registered (in the same files in fact). Every single JS or binary component will need fixes to support this. The amount of work to do is fairly trivial per component and it is possible to support both old and new styles of registration in the same component but until that work is done your components will not work.

Starting extension components later

Currently there are a bunch of different notifications that components can listen for to perform actions during startup. Commonly xpcom-startup, app-startup and profile-after-change have been the most common. The latter is generally the best to use since this is one of the earliest notifications that occurs after the profile folder (and hence preferences and other services) is available.

The news is that once we make our changes components from extensions will no longer be able to register for and receive the xpcom-startup or app-startup notifications at all. profile-after-change will be the first notification that components can be loaded by.

Most of the reasons for loading on app-startup were either because developers didn’t know about profile-after-change or at one point it used to be necessary to load for app-startup just to be able to register for profile-after-change in the observer service. That is no longer the case as you can register for it in the category manager exactly as you can for app-startup.

Why?

You might well ask why we are making all these changes.

Currently whenever we detect a potential change in the set of usable components (meaning either the application version has changed or an extension has been added/removed/enabled/disabled) we must throw away existing component registrations and then perform what has become known as the EM restart where the application is restarted during its startup (in theory invisibly to the user) to make sure that any component that weren’t meant to be loaded are unloaded and to re-register everything and load any new components that need it.

Registration is itself a costly process since every component must be loaded and executed when really many if not most of them do not need to be loaded during startup. In the E10S world there are even more problems. Content processes must either register all components during every startup or somehow share a component cache with the chrome process.

The new registration model allows us to do away with the EM restart. On startup rather than relying on a potentially stale component cache we will read the registrations for the main application out of a manifest file. This will give us enough of XPCOM to then be able to load the extension manager and do any necessary work to install/uninstall/update any extensions after which we can simply load the component registrations for those out of the manifest file. Startup then just proceeds as normal, no restart is necessary since nothing from extensions can have been loaded when it shouldn’t.

E10S content processes can just read the component registrations during startup, since they are in simple manifest files this will go a lot faster

6 thoughts on “Multiple breaking changes are coming for components in extensions”

  1. (I’ve already looked at the registration changes in m.d.t.plat; hopefully there will be more details soon! The wiki page is still rather barren.) Actually – it doesn’t seem to say how to differentiate between whether you want to be in the content process… hmm, I have vague memories of “never”, but I need to find the sources for that.

    Would XR applications still get app-startup (since, presumably, the app stuff would be read in before creating the profile)? Is there some bug or other document with more information on this?

    1. The current plan is that only libxul components will be in the content process, even app-provided components won’t be included.

      I will have to check on application components to be sure but I believe they will get xpcom-startup and app-startup as normal since they should be getting registered at the same time as libxul components.

    2. Don’t expect any non-libxul component access in the “content” process. In fact, depending on how much sandboxing we eventually employ, you may have no component access.

      Start learning how to use the messaging system (Message Manager) to communicate with the main process.

  2. I hope there will still be some chance to activate the JS Debugger for all of the application, which means it needs to be activated _before_ any JS script at all is being loaded.

  3. What about the components registered in the “JavaScript global constructor” or “JavaScript global property” category and exposing the Ci.nsIClassInfo.DOM_OBJECT flag ?

    1. You will have to do your category registrations in the manifest file rather than during component registration but otherwise there is nothing changing about this case.

Comments are closed.