Bug 260337 – new URL("file:///path").origin returns "file://" instead of "null"

• Status: NEW
• Component: New Bugs

[Karl Dubost]

Some of the fails in these series of tests. 
https://wpt.fyi/results/url?label=master&label=experimental&aligned&q=safari%3Afail%20chrome%3Afail%20firefox%3Apass



In Safari and Chrome

new URL("blob:file://host/path").origin 
   "file://"
new URL("file://host/path").origin 
   "file://"
new URL("file:///path").origin 
   "file://"

in Firefox

new URL("blob:file://host/path").origin
    "null"
new URL("file://host/path").origin
    "null"
new URL("file:///path").origin
    "null"

Example
https://wpt.fyi/results/url/a-element-origin.html
FAIL message: assert_equals: origin expected "null" but got "file://"

Cf
https://url.spec.whatwg.org/#special-scheme
https://url.spec.whatwg.org/#concept-url-scheme
https://url.spec.whatwg.org/#origin

The specs says for the file scheme

> Unfortunate as it is, this is left as an exercise to the reader. 
> When in doubt, return a new opaque origin.


which seems to imply to return null. 

but this sentence is probably not necessary and confusing:
" Unfortunate as it is, this is left as an exercise to the reader. "

[Radar WebKit Bug Importer]

<rdar://problem/114015467>

[Anne van Kesteren]

I'm changing the tests in https://github.com/web-platform-tests/wpt/pull/41158 which would resolve the WPTImpact. I also don't think there's BrowserCompat here as at least Chromium does the same thing.

We might still want to fix this though. Returning "file://" is not exactly helpful. Might have to be done at the point where we actually serialize the origin though to not upset origin comparisons and such.