1239990 - location.replace for invalid urls doesn't throw

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Adrián Seijo]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.71 Safari/537.36

Steps to reproduce:

Steps to reproduce
Go to any page
Open the console
Write window.location.replace('//')


Actual results:

The browsers opens http:/// and shows an error html page with the message "The address isn't valid"


Expected results:

According to the spec https://www.w3.org/TR/html5/browsers.html#dom-location-replace and the MDN https://developer.mozilla.org/en-US/docs/Web/API/Location/replace for invalid urls replace should throw an exception instead of doing the navigation and showing an error page.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Can you explain why you think the spec should throw an exception here?  "http:///" is a syntactically valid URL, afaict; it's just not one that can be _loaded_.  But that shouldn't lead to a synchronous exception here unless I'm missing something.

Comment 2

[Adrián Seijo]

Sorry I think that I didn't explain it well enough, I reported it to all the browsers so it gets a bit confusing all the different cases.

So if you go to https://mozilla.org and to window.location.replace('//', location.origin)  Firefox actually throws and exception (so far is the only one that does):

[Exception... "The URI is malformed"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 1"  data: no]

And then navigates to "http:///".

So according to the browser the url is invalid but the browser still try to load it but it does something strange and loads that "http:///". I think that the right behaviour here is to actually not navigate to that url at all since we already have the exception.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Ah, I think that throwing is buggy, per spec.  At least at first glance.  If you see a part of the spec here that says to throw, please do point me to it.

Anyway, what's happening is that nsDocShell::InternalLoad returns NS_ERROR_MALFORMED_URI _and_ loads an error page.  Seems to me like we should do one or the other but not both.

Alternately, the location code should ignore errors from nsDocShell::LoadURI, though seems like there might be cases where we do in fact want to throw from here.

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

https://html.spec.whatwg.org/multipage/browsers.html#dom-location-replace

> Resolve url, relative to the API base URL specified by the entry settings object and let parsedURL be the resulting parsed URL.
> 
> If this is not successful, throw a SyntaxError exception and abort these steps.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3832

Comment 5

[Boris Zbarsky [:bzbarsky]]

Note that your live DOM viewer testcase uses a different relative URI.

> If this is not successful, throw a SyntaxError exception and abort these steps.

Yes, but in this case (replace("//")) that part _is_ successful.

And it has to be, in fact, because that part of URL processing is scheme-agnostic afaict and there are schemes where the URI "scheme:///" is in fact totally reasonable.  "file" comes to mind.

Comment 6

[Adrián Seijo]

Well its true that in the file context that can be a valid url, I think that the problem might be the fact that if you go to "https://mozilla.org" and you do "new URL('//', location.origin)" the generated url is "https:///". It seems to be detecting '//' as an absolute url, and it is, but then its doing something wrong with the schema? As far as I know if you do //mozilla.org/index.html you mean that the browser should infer the schema form the current one is't it?

Comment 7

[Adrián Seijo]

Well for reference here and in order to add more points of view to this issue the Chromium agree that the right behaviour should be throwing and its fixed in the latest canary:

https://bugs.chromium.org/p/chromium/issues/detail?id=578072#c5

Comment 8

[Boris Zbarsky [:bzbarsky]]

Looking at the spec again looks like https://url.spec.whatwg.org/#no-scheme-state is not in fact scheme-agnostic (see step 3).  

So then this needs to be fixed in docshell, as per comment 3.

Comment 9

[John Dai[:jdai]]

I use firefox nightly 51.0a1 with mac OSX 10.11.6, it doesn't navigate to an error page. Only get [Exception... "The URI is malformed"  nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"  location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 1"  data: no]

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.