1110123 - e10s: multiprocessShims.js doesn't interpose nsIAboutModule's registered via chrome.manifest

Status: RESOLVED WONTFIX

(Firefox :: Untriaged, defect)

Description

[Denis]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0
Build ID: 20141126041045

Steps to reproduce:

In Firefox extension:
When e10s is enabled in Nightly I try to embed .xul page in extension html page by IFRAME.

Example:

<iframe src="chrome://addon/page.xul" type="chrome"></iframe>


Actual results:

I am getting blank frame. I also tried to register XUL urls as "about:addonpage" url, but getting "URL is incorrect error", but this url works fine when entered in urlbar directly.


Expected results:

Iframe should be loaded?
With e10s disabled iframe loads properly. There is any way to embed XUL into HTML by IFRAME when e10 is activated?

Comment 1

[:Gijs (he/him)]

Mike, do you have answers here? :-)

Comment 2

[Mike Conley (:mconley) (:⚙️)]

It's not entirely unsurprising that you're having a hard time display add-on provided XUL in content in an iframe. XUL in content is something that we're likely only going to support minimally, and there are certain bits of it (popups, for example) that simply will not work (and might cause tab crashes!).

The about: page problem is interesting, because we do have a shim that makes it so that add-ons can register about: pages and access them from the content process. The reason why you'd be able to access it from the URL bar is because we special-case most about: pages in the URL bar so that they open in the chrome process (notice that the underline goes away in the tab title - that means that the browser is no longer running in a remote process).

I actually just landed a test to ensure that the about: shimming works and can be accessed in the content process, so this is particularly interesting for me.

Can you attach your add-on, or a minimal add-on, that registers the about: page, and has the problem you describe?

Comment 3

[Denis]

Attachment: extension

Comment 4

[Denis]

Thank you for response, attachment added. You can see behaviour by accessing url chrome://fvd.speeddial/content/fvd_about_blank.html.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Ok, yes, I'm seeing this bug with your add-on. I have a feeling we're not shimming your about: handler because it's being registered via a chrome.manifest.

I'm going to try to put together a minimal test case.

Comment 6

[Mike Conley (:mconley) (:⚙️)]

Attachment: bug-1110123-test-addon.xpi

Added minimal testcase add-on. Install add-on, and then visit chrome://bug1110123/content/test.html.

ER: iframe should load about:bug1110123 (which should display a "success" message)

AR: iframe should address isn't valid error.

It looks to me as if multiprocessShims.js doesn't try to interpose the nsIAboutModule defined in components/about_bug1110123.js, and registered in chrome.manifest.

Comment 7

[Allison Naaktgeboren :ally]

..we only shim in js. this would be c++

Comment 8

[Pavel Scherbakov]

Did you fix it or it's in process? We can't make support of es10 in our extension having this bug. This extension is of the highest ranked extensions on Mozilla.

Comment 9

[Pavel Scherbakov]

Chris, problem with that extension which is also mine.
https://addons.mozilla.org/en-US/firefox/addon/fvd-speed-dial/

Comment 10

[Gabor Krizsanits (INACTIVE)]

(In reply to Pavel Scherbakov from comment #8)
> Did you fix it or it's in process? We can't make support of es10 in our
> extension having this bug. This extension is of the highest ranked
> extensions on Mozilla.

I'm looking into this but it seems like a very hard problem. What you can do for sure and it should work already is to register your protocol from script instead of using the chrome.manifest. So something like Components.manager.nsIComponentRegistrar.registerFactory(CLASS_ID, CLASS_NAME, CONTRACT_ID, FACTORY);

That will trigger the shim layer to take care of your protocol from the content process as well.

Comment 11

[Gabor Krizsanits (INACTIVE)]

Whoops hit enter accidentally, and sent the needinfo too soon. Anyway, I looked into the chrome.manifest usage among add-ons and it worries me quite a bit. I see tons of about protocol usages (for which the above mentioned workaround should work in most cases I guess) but there are other interesting cases. There are about 2-300 add-ons that registers some contract that we might care about (more than half of them are protocol related).

Here are the types of contracts we might care about from the content process:

- other network protocols (irc,ircs,geolocater,mailto,etc) actually even totally custom ones, one might use the add-on for injecting an iframe with that protocol in the src...
- content-policy
- streamconv
- uriloader
- calendar
- mime

Honestly, I don't see an easy way to fix this problem, so I'm kind of stuck here. Will keep thinking about what we could do about all these, but was wondering about your opinion too.

Comment 12

[Gabor Krizsanits (INACTIVE)]

Maybe when we parse the manifest, and register the factories, we could check the factory object if it implements some special interface. The interface would have a function that sends out a message to the child processes to register a placeholder factory. This special factory would return a proxy object around a CPOW. So each time someone creates a new instance in the content process, we create one in the chrome process as well, and since native methods can't deal with CPOWs we just wrap the CPOW in a proxy object. It's quite crazy but I don't really have any better ideas... It's also somewhat limiting, but might be better than what we have...

Comment 13

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

I think these add-ons will just have to be fixed manually.

Comment 14

[Gabor Krizsanits (INACTIVE)]

(In reply to Bill McCloskey (:billm) from comment #13)
> I think these add-ons will just have to be fixed manually.

I guess then we should write some docs about this. CC-ing Will to put this on his radar. I think both the chrome.manifest docs and the limitation of frame scripts should be updated. An example of how to get around this problem would be nice too. In a nutshell add-ons cannot use the chrome.manifest to register anything that is available from the content process. For that the factory has to be registered manually from a process script.

Comment 15

[ArturD]

Hi, We just uploaded new version compatible with es10. It fully redesigned. Please check ASP.