1215793 - WebNavigation:LoadURI returns error NS_ERROR_MALFORMED_URI in e10s

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect)

Description

[testit]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build ID: 20150929144111

Steps to reproduce:

- Occurred in Firefox 43/44 nightly in a e10s window.

- Install my add-on EPUBReader: https://addons.mozilla.org/en-US/firefox/addon/epubreader/.

- Open a e10s window.

- Open scratchpad in browser context and run the following code:
var webnav =
Components.classes["@mozilla.org/appshell/window-mediator;1"].
getService(Components.interfaces.nsIWindowMediator).
getMostRecentWindow("navigator:browser").getBrowser().
selectedBrowser.webNavigation;

webnav.loadURI('about:epubreader?id=1', webnav.LOAD_FLAGS_NONE, null, null, null);

- URL is not opened, this error is displayed in error console: 
Error: NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIWebNavigation.loadURIWithOptions]
Source File: chrome://global/content/browser-child.js
Line: 300

- Open a non e10s window and run the same javascript code in scratchpad. The URL is opened, no error is displayed in error console.

Comment 1

[Benjamin Smedberg]

Totally not an XPCOM bug. Presumably e10s requires that you register about: handlers in some new way, but I don't know what that is.

Comment 2

[testit]

If you enter the url directly in the Firefox URL bar, the page is displayed without problems. The error only occurs, if the URL is opened via webNavigation.loadURI.

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

Gabor, what's the right way to register about: protocol handlers to make this work?

Comment 4

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

Our shims support registering about: modules. Here are our tests for that:

https://dxr.mozilla.org/mozilla-central/rev/9605da94e75d61598d3c00f01a12d1b6bc427a6c/toolkit/components/addoncompat/tests/addon/bootstrap.js#270

Comment 5

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

Note, however, that I don't think we support registering about: modules from chrome.manifest - if that's how EPUBReader is doing it, that'd explain it.

Comment 6

[testit]

(In reply to Mike Conley (:mconley) - Needinfo me! from comment #5)
> Note, however, that I don't think we support registering about: modules from
> chrome.manifest - if that's how EPUBReader is doing it, that'd explain it.

If I enter the URL directly in the Firefox URL bar, it can be opened without problems. The error only occurs, if it is opened via webNavigation.loadURI, so I don't think that there is a problem with the about module registration.

Comment 7

[Gabor Krizsanits (INACTIVE)]

Registration can either happen in the content process or in the chrome process or both. Respectively it will work in the process where it was registered. For add-ons we have a shim layer, that automatically does the registration for you in the content process when you register it on parent side, but best practice is not to rely on it since shims will not last forever. And as Mike said registration from chrome.manifest is no longer supported (or to be precise it will only do the registration in the chrome process and it's rarely what people need).

URL bar belongs to the chrome process so when you execute your code with the browser context in scratchpad I assume that script is run in that process too so that will do the registration in the chrome process. However selectedBrowser is a remote browser, it's content window is in the content process, so when you navigate it, all that will happen on content side hence it will not work (that's my bet at least). So to make it work you should run your registration code as a process-script (http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIMessageManager.idl#442). You can use a data URL for that API, here is an example usage: http://mxr.mozilla.org/mozilla-central/source/dom/base/test/browser_messagemanager_loadprocessscript.js#58

Comment 8

[Paul Heil]

I am getting this same error when opening about pages using 

    tabs.open({
        url: url,
        isPinned: true,
        inNewWindow: false,
        inBackground: false
    });

Same as OP it will open fine when manually typed.  I am registering my about pages in index.js for my e10 enabled SDK add-on.  Contrary to OP this just stopped working for me in FF45b3 or FF45b2 (forget which)

Comment 9

[Loic]

Paul, could you file a new bug with testcase, please (Copy the bug number here).

Comment 10

[Paul Heil]

Related bug with testcase: bug 1247402

Comment 11

[noitidart]

Does this page need to be updated -

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

In e10s I wasn't able to use the URI_MUST_LOAD_IN_CHILD flag. So I removed it and used the URI_CAN_LOAD_IN_CHILD flag.

Comment 12

[noitidart]

Also if the about: page is defined to redirect to a chrome:// path, will the flags set in the chrome.manifest such as `remoteenabled` and `remoterequired` fight with the `URI_MUST_LOAD_IN_CHILD`/`URI_CAN_LOAD_IN_CHILD` flags? It would be nice if we can explain how this works on the doc page linked in one comment above  (Comment #11)