Bug 260337 - new URL("file:///path").origin returns "file://" instead of "null"
Summary: new URL("file:///path").origin returns "file://" instead of "null"
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari 17
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: BrowserCompat, InRadar, WPTImpact
Depends on:
Blocks: 128023
  Show dependency treegraph
 
Reported: 2023-08-17 01:57 PDT by Karl Dubost
Modified: 2023-08-18 04:02 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Dubost 2023-08-17 01:57:47 PDT
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. "
Comment 1 Radar WebKit Bug Importer 2023-08-17 01:57:54 PDT
<rdar://problem/114015467>
Comment 2 Anne van Kesteren 2023-08-18 03:03:55 PDT
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.