Closed
Bug 1257201
Opened 8 years ago
Closed 8 years ago
With e10s enabled, custom about pages with flags URI_CAN/MUST_LOAD_IN_CHILD not registering successfully from chrome process
Categories
(Core :: DOM: Security, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: noitidart, Unassigned)
References
Details
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.
Component: Untriaged → DOM: Security
Depends on: 1254752
Product: Firefox → Core
Version: 46 Branch → 47 Branch
Comment 1•8 years ago
|
||
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
Thanks quicksaver, I tested on linux, will test again tonight.
(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•8 years ago
|
||
Confirmed. And like for most other related problems, if you register the about: handler in the child process, the problem goes away.
Summary: New custom about page method doesn't work in Fx47 or Fx48 → With e10s enabled, custom about pages with flags URI_CAN/MUST_LOAD_IN_CHILD not registering successfully from chrome process
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.
Updated•8 years ago
|
Flags: needinfo?(mconley)
Comment 6•8 years ago
|
||
(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.
Flags: needinfo?(mconley)
Comment 7•8 years ago
|
||
Is this still a problem notidart, or can we close this out?
Flags: needinfo?(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?
Flags: needinfo?(noitidart)
Comment 9•8 years ago
|
||
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
Flags: needinfo?(noitidart)
Reporter | ||
Comment 10•8 years ago
|
||
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
Flags: needinfo?(noitidart) → needinfo?(quicksaver)
Comment 11•8 years ago
|
||
(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?
Flags: needinfo?(quicksaver) → needinfo?(mconley)
Comment 12•8 years ago
|
||
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.
Flags: needinfo?(mconley)
Comment 13•8 years ago
|
||
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.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 14•8 years ago
|
||
(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?
Reporter | ||
Comment 15•8 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•