Status

()

defect
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: emk, Assigned: emk)

Tracking

(Depends on 1 bug, Blocks 1 bug, {dev-doc-complete})

unspecified
mozilla12
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-Opera])

Attachments

(1 attachment, 1 obsolete attachment)

Assignee

Description

8 years ago
Per bug 699857, data URIs are considered as same-origin in Gecko.
We already allow XHR to blob URLs. Again, there is no point rejecting only data URLs.
This makes it harder for JavaScript libraries to detect HTML parsing support in XHR locally (without GETing an HTTP resource).
Assignee

Comment 2

8 years ago
Posted patch patch (obsolete) — Splinter Review
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #584323 - Flags: review?(bugs)
Comment on attachment 584323 [details] [diff] [review]
patch

Sicking should review all the CORS changes.

And this needs tests
Attachment #584323 - Flags: review?(bugs) → review?(jonas)
Comment on attachment 584323 [details] [diff] [review]
patch

The @font-face should possibly also use this new mechanism. It currently uses a different way to enable data-urls together with CORS-listeners.

However it's possible that the @font-face code needs to keep doing special things since it might want to sync-load data urls. If that's not the case, then please file a followup or attach another patch here.
Attachment #584323 - Flags: review?(jonas) → review+
I'm wondering if having xhr.status return 0 is a good idea. We do that file:// urls, and that's bitten me a number of times already
Assignee

Updated

8 years ago
Blocks: 716489
Assignee

Comment 6

8 years ago
> However it's possible that the @font-face code needs to keep doing special
> things since it might want to sync-load data urls. If that's not the case,
> then please file a followup or attach another patch here.
Files bug 716489.
(In reply to Ms2ger from comment #5)
> I'm wondering if having xhr.status return 0 is a good idea. We do that
> file:// urls, and that's bitten me a number of times already

FWIW, I have been confused by status returning 0 instead of 200 for successful non-HTTP responses. Maybe a follow-up bug?
Assignee

Comment 8

8 years ago
(In reply to Henri Sivonen (:hsivonen) from comment #7)
> (In reply to Ms2ger from comment #5)
> > I'm wondering if having xhr.status return 0 is a good idea. We do that
> > file:// urls, and that's bitten me a number of times already
> 
> FWIW, I have been confused by status returning 0 instead of 200 for
> successful non-HTTP responses. Maybe a follow-up bug?

Filed bug 716491.
Assignee

Comment 9

8 years ago
Posted patch patch v2Splinter Review
The previous patch caused test failure.
Also added a test case.
Try result:
https://tbpl.mozilla.org/?tree=Try&rev=4407d2e1a107
Attachment #584323 - Attachment is obsolete: true
Attachment #586993 - Flags: review?(jonas)
Assignee

Updated

8 years ago
Keywords: checkin-needed
Hmm.  Do we really want to check for the "data" scheme here?  Or for the "inherits security context" flag?  Seems like the latter would make more sense to me....  (General note: any time you're checking string schemes the code is probably wrong.)
Assignee

Comment 11

8 years ago
I'm not sure we should allow XHR to "wyciwyg:"/"javascript:" URIs.
(Opera do not allow XHR to "javascript:" URIs)
> I'm not sure we should allow XHR to "wyciwyg:"/"javascript:" URIs.

Why not?

And even if we grant that, do you want to allow it to all LOCAL_RESOURCE urls that inherit the security context?
Actually.... shouldn't this check just be identical to the SVG image stuff in nsDataDocumentContentPolicy::ShouldLoad?  That is, should XHR to a -moz-filedata URL, say, work?
Assignee

Comment 14

8 years ago
XHR to blob URIs already works since Firefox 9.
Assignee

Comment 15

8 years ago
(In reply to Masatoshi Kimura [:emk] from comment #14)
> XHR to blob URIs already works since Firefox 9.
Sorry, since Firefox 6 (that is, since MozBlobBuilder has been supported).
Assignee

Updated

8 years ago
Depends on: 716820
Assignee

Comment 16

8 years ago
Filed bug 716820 because Workers also check the hard-coded scheme name.
> XHR to blob URIs already works since Firefox 9.

OK, why?  What sort of check is _that_ doing?

Keep in mind that extensions can implement protocols too; the question is which of those XHR should work to.
Assignee

Comment 18

8 years ago
(In reply to Boris Zbarsky (:bz) from comment #17)
> OK, why?  What sort of check is _that_ doing?
Apparently that's because blob URIs implement nsIURIWithPrincipal.
NS_SecurityCompareURIs will get a principal URI if the URI implements the interface.
For data URIs, NS_SecurityCompareURIs will fail because data URIs don't support nsIURIWithPrincipal and the scheme doesn't match with the loading document ("data" vs "http"/"file").
Ah, ok.  That makes sense.
http://hg.mozilla.org/integration/mozilla-inbound/rev/9f1349e72752
Flags: in-testsuite+
Keywords: checkin-needed
Target Milestone: --- → mozilla12
https://hg.mozilla.org/mozilla-central/rev/9f1349e72752
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Documented:

https://developer.mozilla.org/en/DOM/XMLHttpRequest#Gecko_notes

Mentioned on Firefox 12 for developers.
You need to log in before you can comment on or make changes to this bug.