E10S XPCOM components in extension/chrome.manifest not registered in content process

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
8 years ago
4 years ago

People

(Reporter: athamala, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Build Identifier: Mozilla 5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100915 Firefox/4.0b7pre Fennec/2.0b1pre

In E10s, only XPCOM components registered from greDIR/chrome.manifest are loaded into content process. Components listed in extensions/{extension-id}/chrome.manifest are not registered in content process. 

This breaks extensions, that implement for example stream converters using nsIStreamConverter, nsIStreamListener, nsIRequestObserver as an XPCOM component.

Working around this by including contract and component registration for these components in GREDIR/chrome.manifest results in working extensions (if they are up to date otherwise)


Reproducible: Always




WMLBrowser at http://wmlbrowser.mozdev.org/ is a good example of this (needs small version number changes to install into latest versions).

Comment 1

8 years ago
At this point we do not intend to register extension XPCOM components in content processes. If you have specific tasks you want to accomplish in content processes which are not possible without registered components, you can either:

* file a bug for a programmatic API to accomplish these tasks (preferable)
* manually register the component (nsIComponentRegistrar) using message-manager scripts
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WONTFIX
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> * manually register the component (nsIComponentRegistrar) using
> message-manager scripts

Could you elaborate more on this subject, e.g. docs, references or examples? Looks like PDF.js needs to do just that.
Flags: needinfo?(benjamin)

Comment 3

5 years ago
Discussed on IRC.
Flags: needinfo?(benjamin)
See Also: → bug 980161
Could you give me some guidance Benjamin? I'd like to get pdf.js working in e10s. I think I basically just need to call the init() method in PdfJs.jsm. However, that JSM is located in browser/extensions/pdfjs/content. There's a simple chrome.manifest file in the parent directory that contains:

resource pdf.js content/

From nsBrowserGlue we use a resource://pdfjs/ URL to import the module. I'd like to do the same thing from the content process, but I don't know how to get a URL for it.
Flags: needinfo?(benjamin)

Comment 5

4 years ago
pdf.js isn't an extension any more, is it? I'm not sure I understand what advice you're looking for. Use the message manager to get code into the content process, and if you really need to register new URLs, use nsIComponentRegistrar.autoRegister(manifest) to do it.
Flags: needinfo?(benjamin)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #5)
> pdf.js isn't an extension any more, is it? I'm not sure I understand what
> advice you're looking for. Use the message manager to get code into the
> content process, and if you really need to register new URLs, use
> nsIComponentRegistrar.autoRegister(manifest) to do it.

How do I get an nsIFile that points to the chrome.manifest? Won't it be packed up in the omnijar somewhere? The problem I'm having is just figuring out how to locate these resources.
You need to log in before you can comment on or make changes to this bug.