878297 - window.location.origin is "null" for file: URIs

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[blois]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.93 Safari/537.36

Steps to reproduce:

Open an HTML file from local file system (with a file:/// URI).

Check window.location.origin.


Actual results:

Got the string value "null"


Expected results:

Expected: "file://"

Note that the spec appears to be a bit lenient in this area: http://tools.ietf.org/html/rfc6454#section-4

"If uri-scheme is "file", the implementation MAY return an implementation-defined value."

But all other browsers return "file://" for the origin in this case.

Comment 1

[Boris Zbarsky [:bzbarsky]]

"null" is in fact correct, because file:// doesn't use a hierarchical element as a naming authority in Gecko.

Returning "file://" would lead to incorrect security checks, which is highly undesirable from my point of view.

Comment 2

[Mounir Lamouri (:mounir)]

We could also return the file path as an origin. Some origin definitions require that IIRC.

Comment 3

[laurent combe]

the spec is laxist : "the implementation MAY return an implementation-defined value"

but "null" value can not permit to make difference between
- use of file:// scheme
- don't use CORS specification

please modify the 'null' value
or permit to change it by 'configuration' option

Comment 4

[Ludovic Hirlimann [:Usul]]

(In reply to Boris Zbarsky [:bz] from comment #1)
> "null" is in fact correct, because file:// doesn't use a hierarchical
> element as a naming authority in Gecko.
> 
> Returning "file://" would lead to incorrect security checks, which is highly
> undesirable from my point of view.

Boris,
This makes people who want to contribute to OSM , have to use IE, not firefox :(. I can provide a set of files that list cities were suff needs to happend. The osm server blocks because of the null value. What's the way forward for this ?

Comment 5

[laurent combe]

Attachment: local.xml

Comment 6

[laurent combe]

Attachment: filter.xsl

Comment 7

[laurent combe]

to reproduce the issue i attached two files (local.xml and filter.xsl)

- put local.xml and filter.xsl on a same local directory
- open with firefox the file local.xml
result : a blank page with a error message in console about a CORS request

if i open local.xml with a Internet Explorer 8 on a windows 7  (ugly for working with osm data :-) 
it works :-(((

Comment 8

[Boris Zbarsky [:bzbarsky]]

laurent, that sounds like a separate bug involving XSLT, not the stringification of origins per se, which you should probably file separately from this bug...

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't understand the purpose of sending "file://". How does "file://" tell you more than "null"?

Is there a case where you'd want to allow a resource to be loaded by unknown files on a user's filesystem (a file which might have been downloaded from anywhere on the web), but you don't trust other unknown files from the web?

Comment 10

[exa.exa]

Hello,
is there please any update on this?

I'd like to also report one additional nuisance w.r.t. to the "null" answer -- it is a string "null" instead of the actual javascript null that would be more appropriate in this place, leaving developers no chance to reasonably catch this in their code. If nothing, this sole problem should be considered a bug and be fixed.

I can probably submit a patch if pointed to the code that does this (I'm new to gecko dev, crawling through the repo will take some time).
Thanks!