1257201 - With e10s enabled, custom about pages with flags URI_CAN/MUST_LOAD_IN_CHILD not registering successfully from chrome process

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[noitidart]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160307215824

Steps to reproduce:

I followed the new custom about page URI example we updated:

    newChannel: function(aURI, aSecurity_or_aLoadInfo) {
        var channel;
        if (Services.vc.compare(Services.appinfo.version, '47.*') > 0) {
              let uri = Services.io.newURI(aboutPage_page, null, null);
              // greater than or equal to firefox48 so aSecurity_or_aLoadInfo is aLoadInfo
              channel = Services.io.newChannelFromURIWithLoadInfo(uri, aSecurity_or_aLoadInfo); 
        } else {
              // less then firefox48 aSecurity_or_aLoadInfo is aSecurity
              channel = Services.io.newChannel(aboutPage_page, null, null);
        }


Actual results:

It uses the old method for Fx47 and the new method for Fx48. About page is not loading, it gives malformed uri error with loadUriFromUriWithOptions (off the top of my head)

I also tried using the new method in Fx47, it didnt work there either. What was really confusing me was that the new (Fx48+) method worked for me on Fx45 and Fx46.


Expected results:

The code from example page should work n Fx47 and Fx48.

Comment 1

[Luís Miguel [:quicksaver] (not reading bugmail)]

Works for me in windows, literally copy-pasted from the example [1], minus a few nits here and there for missing semicolons.

[1] https://developer.mozilla.org/en-US/docs/Custom_about:_URLs

Comment 2

[noitidart]

Thanks quicksaver, I tested on linux, will test again tonight.

Comment 3

[noitidart]

(In reply to Luís Miguel [:quicksaver] from comment #1)
> Works for me in windows, literally copy-pasted from the example [1], minus a
> few nits here and there for missing semicolons.
> 
> [1] https://developer.mozilla.org/en-US/docs/Custom_about:_URLs

Ah it's the flag of  | Ci.nsIAboutModule.URI_CAN_LOAD_IN_CHILD that is messing it up. Can you please try that quicksaver.

Comment 4

[Luís Miguel [:quicksaver] (not reading bugmail)]

Confirmed. And like for most other related problems, if you register the about: handler in the child process, the problem goes away.

Comment 5

[noitidart]

Thanks very much @quicksaver for the help on this.

So our question is:

Does the handler have to be registered in the child process in addition to the parent (chrome) process if we want to use these flags? This feels like a workaround. We should be able to register it from the chrome process.

Comment 6

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

(In reply to noitidart from comment #5)
> Thanks very much @quicksaver for the help on this.
> 
> So our question is:
> 
> Does the handler have to be registered in the child process in addition to
> the parent (chrome) process if we want to use these flags? This feels like a
> workaround. We should be able to register it from the chrome process.

No, you should be able to register the about pages in the parent with those flags.

Comment 7

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

Is this still a problem notidart, or can we close this out?

Comment 8

[noitidart]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #7)
> Is this still a problem notidart, or can we close this out?

Thanks for the comment #5, I am not able to register from the parent though with that code above. I haven't tried since a few days ago though should I try again in nightly?

Comment 9

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

Do you have the multiprocessCompatible flag set in install.rdf? If so, you'll be bypassing the shims, which will prevent the registration from occurring.

Here's one of our automated tests where an add-on running in the parent process registers an nsIAboutModule page; http://searchfox.org/mozilla-central/source/toolkit/components/addoncompat/tests/addon/bootstrap.js#495

Comment 10

[noitidart]

Ah (In reply to Mike Conley (:mconley) - Needinfo me! from comment #9)
> Do you have the multiprocessCompatible flag set in install.rdf? If so,
> you'll be bypassing the shims, which will prevent the registration from
> occurring.
> 
> Here's one of our automated tests where an add-on running in the parent
> process registers an nsIAboutModule page;
> http://searchfox.org/mozilla-central/source/toolkit/components/addoncompat/
> tests/addon/bootstrap.js#495

Oh! Yes I do have multiprocessCompatible flag set. I wanted to avoid all shims at all costs. What is this shim doing? Is it registering it in each child process?


But I think @quicksaver above ran into this issue when installing it from the scratchpad

Comment 11

[Luís Miguel [:quicksaver] (not reading bugmail)]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #6)
> No, you should be able to register the about pages in the parent with those
> flags.

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #9)
> Do you have the multiprocessCompatible flag set in install.rdf? If so,
> you'll be bypassing the shims, which will prevent the registration from
> occurring.

I may be missing something, but these seem to contradict each other. It either *should* register the about: handler in the child process when using the URI_CAN_LOAD_IN_CHILD flag (regardless of multiprocessCompatible), or the fact that it does now is just a shim, which is to say a workaround itself, and the add-on should optimally do that by itself (which would make this a WONTFIX, no?)

(In reply to noitidart from comment #10)
> Oh! Yes I do have multiprocessCompatible flag set. I wanted to avoid all
> shims at all costs. What is this shim doing? Is it registering it in each
> child process?
> 
> But I think @quicksaver above ran into this issue when installing it from
> the scratchpad

Form the console actually, copy-pasting almost directly from the docs. Do/should those shims work there as well?

Comment 12

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

Sorry for the delay.

(In reply to Luís Miguel [:quicksaver] from comment #11)
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #6)
> > No, you should be able to register the about pages in the parent with those
> > flags.
> 
> (In reply to Mike Conley (:mconley) - Needinfo me! from comment #9)
> > Do you have the multiprocessCompatible flag set in install.rdf? If so,
> > you'll be bypassing the shims, which will prevent the registration from
> > occurring.
> 
> I may be missing something, but these seem to contradict each other. It
> either *should* register the about: handler in the child process when using
> the URI_CAN_LOAD_IN_CHILD flag (regardless of multiprocessCompatible), or
> the fact that it does now is just a shim, which is to say a workaround
> itself, and the add-on should optimally do that by itself (which would make
> this a WONTFIX, no?)

I believe that if you register an nsIAboutModule in the parent process, when the parent attempts to access the about: pages, it should choose the right remoteness to load the page in based on URI_CAN_LOAD_IN_CHILD or URI_MUST_LOAD_IN_CHILD.

If the content process attempts to load an about: page on its own, I don't believe it will be able to access it, unless shims are enabled, since the add-on shims are doing the work of registering the same nsIAboutModule in the content process as in the parent.

Does that make sense?

So, to answer the original question - "Does the handler have to be registered in the child process in addition to the parent (chrome) process if we want to use these flags? This feels like a workaround. We should be able to register it from the chrome process.", the answer is:

Yes, I believe you do, if you want the content process to be able to load those pages (in, for example, an iframe). Otherwise, the content process won't know what page you're referring to. If you just set it in the parent process, then the parent will know what to do when you type the URL in the URL bar, since it's doing the work of resolving the about: URL to the "under the hood" URL.

If you have the shims enabled, then registering in the parent process will automatically register it in the content process.

Comment 13

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

Closing as INVALID, because I think we're working as expected. Please re-open if you disagree, and needinfo me if you need further clarification.

Comment 14

[noitidart]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #13)
> Closing as INVALID, because I think we're working as expected. Please
> re-open if you disagree, and needinfo me if you need further clarification.

Oh thanks Mike, so this is a wontfix totally understand. Maybe only action needed is update of the docs to say that it needs to be registered in the content process? So for now once in a tab, but in future once in each tab?

Comment 15

[noitidart]

Updated docs here -  https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Which_URIs_load_where

with this note:

"
If you use these flags, you must register the about page in the framescript for each tab. If you do not set multiprocessCompatible to true in your install.rdf then shims will be used. But the e10s shims will be deprecated soon. Read more here - Bug 1257201.
"

This completes this bug topic i think.

Is there anyway to register about pages with chrome.manifest? That way we don't have to worry about registering them with a framescript if we want to use the CHILD flags?

Like for chrome:// pages if we want them to load in child process we can set it via chrome.manifest - 
    remoteenabled: the page will be loaded in the same process as the browser that has loaded it.
    remoterequired: the page will always be loaded in a child process.

And we don't need any extra framescript stuff here.