I'm trying to override Firefox's default implementation of nsIURIFixup via a Firefox addon. Because this service is created once and then cached globally after the construction of nsDocShell, I have to register my component before any docshell is initialized. Therefore I use chrome.manifest to register my (JS) XPCOM component, including the profile-after-change category to get the component to load as soon as possible.
This works well in single-process Firefox (37), but not when Electrolysis (e10s) is enabled (e.g. in Firefox Nightly). This issue is caused by the fact that an add-on's chrome.manifest is only imported in Firefox's browser process, and not its content processes when e10s is activate (bug 596880, marked as WontFix).
Components can dynamically be registered in the content process by importing a JSM in a frame script which calls the registerFactory method of nsIComponentRegistrar. This probably works for most applications, but not for mine because my component must be initialized before the docshell is constructed, and it appears that frame scripts are loaded too late (i.e. when the docshell has already been constructed).
I've also explored other ways to implement my functionality, such as tracking down and monkey-patching the (indirect) consumers of the interface. I dislike this fragile "solution", because it relies on undocumented implementation details and may therefore break at any point in the future.
It also occurred to me that I could append my component to Firefox's global chrome.manifest, but this seems like a terrible hack as well (what if this file is read-only, e.g. because it is installed by an admin? And what are the odds that AMO accepts an add-on that modifies one of Firefox's core files as a part of its installation...?).
So, how can I properly register a component that loads as soon as a content process is created, such that it can effectively override an implementation of an interface within that process?