[e10s] Components registered in an extension's chrome.manifest file aren't registered in content processes

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
4 years ago
2 years ago

People

(Reporter: mkaply, Unassigned)

Tracking

({addon-compat})

Trunk
addon-compat
Points:
---

Firefox Tracking Flags

(e10s+)

Details

Attachments

(1 attachment)

1.51 KB, application/x-xpinstall
Details
(Reporter)

Description

4 years ago
We use this code in chrome.manifest:

component {49c4f409-eaf5-4c4d-a96a-280a60c7c6b7} components/aboutNetError.js
contract @mozilla.org/network/protocol/about;1?what=neterror {49c4f409-eaf5-4c4d-a96a-280a60c7c6b7}

to provide a custom neterror page.

On e10s, aboutNetError.js never gets loaded at all.

I've verified that on the same build, if I turn off e10s, it loads fine.

Updated

4 years ago
Summary: "WEB.DE MailCheck" add-on does not work with e10s - Unable to override about:neterror → Unable to override about:neterror with e10s - "WEB.DE MailCheck" add-on does not work

Updated

4 years ago
Whiteboard: [e10s]

Updated

4 years ago
tracking-e10s: --- → ?
Whiteboard: [e10s]
(Reporter)

Comment 1

4 years ago
I'm seeing some real strangeness here that i at least want to document.

When I first go to some bad domain, my component did not load. Even if I open a new tab and put in a different bad domain, it doesn't load. Shift reload does caused my component to finally get loaded.

Even then, newChannel is never getting called. Only getURIFlags. I'm experimenting with the return to getURIFlags to see if that is causing the issue. We're currently returning 0.

I'll put together a standalone testcase.
(Reporter)

Comment 2

4 years ago
Created attachment 8561462 [details]
aboutbug.xpi

It's something unique about overriding about:neterror.

Overrriding about:config works fine.

And overriding about:neterror works fine in a non e10s window.
tracking-e10s: ? → +
(Reporter)

Comment 3

4 years ago
Dave:

This is as far as I got.
Flags: needinfo?(dtownsend)
(Reporter)

Comment 4

4 years ago
documentURI is the same in both cases:

about:neterror?e=dnsNotFound&u=http%3A//www.fdasfsdfsdafsdafsda.com/&c=UTF-8&f=regular&d=Firefox%20can%27t%20find%20the%20server%20at%20www.fdasfsdfsdafsdafsda.com.

and explicitly going to about:neterror with or without parameters works.

So it must have to do with the internal transition from the web page URL to about:neterror
(Reporter)

Comment 5

4 years ago
I tried messing around with the various about flags in getURIFlags, but nothing changed the behavior.
Looks like the problem is that the component is never registered in the content process
Flags: needinfo?(dtownsend)
Summary: Unable to override about:neterror with e10s - "WEB.DE MailCheck" add-on does not work → [e10s] Components registered in an extension's chrome.manifest file aren't registered in content processes
Is this intentional Bill or something we should fix?
Flags: needinfo?(wmccloskey)
No, it's not intentional. I think we probably do want to handle these directives from add-ons. I think we should be careful though. Generally add-on code only runs in the parent process, and I think that should continue to be the default. Add-ons should have to opt into loading components in the content process.

We do have a directive, process=main or process=content, that restricts where a component is loaded. Currently if it's absent we load in both. Somehow we'd need to change the default for add-ons to process=main (and add a new process=all option) while keeping the default for Gecko as process=all. Or we could change all the manifest files in Gecko to specify process=all.

An additional wrinkle is that we only load manifest files from toolkit/ into the content process. Stuff in browser/ gets skipped. We also want to preserve that behavior.

I'm all for fixing this, but it will be a bit of work.
Flags: needinfo?(wmccloskey)
It should be possible to do dynamic component registration in the content process to get around this for now. Not ideal but since there is a workaround I'm probably not going to spend time on this right now.
OS: Windows 7 → All
Hardware: x86_64 → All
(Reporter)

Comment 10

4 years ago
> We do have a directive, process=main or process=content, that restricts where a component is loaded. Currently if it's absent we load in both.

If that's the case, why isn't this loading in content?

How is that directive specified? and where is this documented?
(In reply to Mike Kaply [:mkaply] from comment #10)
> > We do have a directive, process=main or process=content, that restricts where a component is loaded. Currently if it's absent we load in both.
> 
> If that's the case, why isn't this loading in content?

The content process doesn't even try to parse manifest files from extensions at the moment.

> How is that directive specified? and where is this documented?

I added some documentation here: https://developer.mozilla.org/en-US/docs/Chrome_Registration#process
(Reporter)

Comment 12

4 years ago
> It should be possible to do dynamic component registration in the content process to get around this for now. Not ideal but since there is a workaround I'm probably not going to spend time on this right now.

Is there a possible this won't make it into e10s at all?

Should I switch to dynamic registration?
(In reply to Mike Kaply [:mkaply] from comment #12)
> > It should be possible to do dynamic component registration in the content process to get around this for now. Not ideal but since there is a workaround I'm probably not going to spend time on this right now.
> 
> Is there a possible this won't make it into e10s at all?
> 
> Should I switch to dynamic registration?

It isn't marked to block release of e10s so unless we up that (because this is a more important problem than we realise) or someone has spare time to work on this it probably won't be in the first e10s releases.

Comment 14

3 years ago
Almost five years ago, a similar feature request was dismissed (bug 596880). But in this bug there seems to be a positive attitude towards loading components within the content process. Bill, what were your concerns back then, and why are they not/less relevant now?

I'm developing an add-on, which fails in e10s because components are not loaded in content processes (https://stackoverflow.com/q/29569487). I think that fixing this bug would be the best way to solve the issue, so I'd like to write a patch.

After reading the source code, I have (shallow) understanding of how Firefox starts up, how extensions are registered and loaded, and when components are initialized. Do you have any tips for writing the patch? In particular, what approaches should I avoid, and which non-obvious gotchas should I be aware of?
Flags: needinfo?(wmccloskey)
Sorry this took me so long to get to. I think the quickest route to getting your extension working is to use a process script [1] to dynamically register the component.

[1] https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Process_scripts
Flags: needinfo?(wmccloskey)
(Reporter)

Comment 16

3 years ago
(In reply to Bill McCloskey (:billm) from comment #15)
> Sorry this took me so long to get to. I think the quickest route to getting
> your extension working is to use a process script [1] to dynamically
> register the component.
> 
> [1]
> https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/
> Message_Manager/Process_scripts

So I did this but now I'm running into another interesting problem.

when I override about:neterror on e10s only, the URL is showing in the URL bar as:

about:neterror?e=dnsNotFound&u=http%3A//www.fsdafsdfsda.com/&c=UTF-8&f=regular&d=Firefox%20can't%20find%20the%20server%20at%20www.fsdafsdfsda.com.

As opposed to being www.fsdafsdfsda.com which it is on non e10S.

I tried experimenting with the URI flags but anything I do to make the URL go back to the way it was:

Ci.nsIAboutModule.URI_SAFE_FOR_UNTRUSTED_CONTENT | Ci.nsIAboutModule.URI_CAN_LOAD_IN_CHILD;

Make the content not work properly because it uses chrome URLs.

Any ideas?
(Reporter)

Comment 17

3 years ago
To answer my own question, it looks like you have to use:

return Ci.nsIAboutModule.URI_CAN_LOAD_IN_CHILD;

Comment 18

2 years ago
Based on the fact that there's a manual workaround mentioned in this bug, it doesn't seem like worth fixing anymore. If you disagree Mike, please re-open.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX

Comment 19

2 years ago
Just a note about the workaround (which is cool): This is the same case when trying to register custom about: pages. The solution by addon devs was to register from framescript, works pretty good. Only issue with that, which I think might affect this also, is when you open a new pointed at that URL, if the registration in the framescript doesn't run early enough, then you will get a bad page error with about: pages. So in the above case, you will get the non-overridden error page. The solution for that was for addon devs to check the tab after registration and reload it if necessary. User sees a visible change in page for a split second, which stinks, but the code is straight forward and makes sense, nothing hacky about it.
(Reporter)

Comment 20

2 years ago
I don't think the workaround is sufficient unless we are going remove the "process=" option from chrome.manifest and change the docs.

If we provide the process=content and that simply doesn't work, why do we offer it?

That's the bug...

Comment 21

2 years ago
I am facing this problem when working on a legacy plugin which uses xpcom and exposes it as a global constructor. Actually the global constructor can be seen in firefox console when a blank tab is opened. But it disappears when any url is loaded and I am not able to use it in page script. I did pretty a lot search and tried different APIs however none works so far. Can anyone provide some more details about how to dynamically register a component and expose it as a global constructor in process script for content process?
(Reporter)

Comment 22

2 years ago
My best suggestion would be to take apart this add-on:

https://addons.mozilla.org/en-US/firefox/addon/webde-mailcheck/

to see the code that was written to do this. I don't have any easy to access examples.
You need to log in before you can comment on or make changes to this bug.