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

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Description

[Arto Hamalainen]

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

[Benjamin Smedberg]

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

Comment 2

[Yury Delendik (:yury)]

(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.

Comment 3

[Benjamin Smedberg]

Discussed on IRC.

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 5

[Benjamin Smedberg]

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.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

(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.