我正在尝试nsIURIFixup通过 Firefox 插件覆盖 Firefox 的默认实现。因为这个服务是创建一次，然后在构建后全局缓存，所以我必须nsDocShell在初始化任何 docshell 之前注册我的组件。因此，我使用chrome.manifest注册我的（JS）XPCOM 组件，包括profile-after-change让组件尽快加载的类别。
这在单进程 Firefox (37) 中运行良好，但在启用电解 (e10s) 时（例如在 Firefox Nightly 中）则不行。这个问题是由于插件chrome.manifest仅在 Firefox 的浏览器进程中导入，而不是在激活 e10s 时其内容进程（错误 596880，标记为 WontFix）。
通过在调用. registerFactory_ nsIComponentRegistrar这可能适用于大多数应用程序，但不适用于我的，因为我的组件必须在构建 docshell 之前初始化，并且看起来框架脚本加载得太晚（即当 docshell 已经构建时）。
我还探索了实现我的功能的其他方法，例如跟踪和猴子修补接口的（间接）消费者。我不喜欢这种脆弱的“解决方案”，因为它依赖于未记录的实现细节，因此可能在未来的任何时候中断。
我还想到我可以将我的组件附加到 Firefox 的 global chrome.manifest，但这似乎也是一个可怕的黑客攻击（如果这个文件是只读的，例如因为它是由管理员安装的呢？AMO 的几率是多少？接受修改 Firefox 的核心文件之一作为其安装的一部分的附加组件...？）。
那么，如何正确注册一个在创建内容进程后立即加载的组件，以便它可以有效地覆盖该进程中的接口实现？