If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Blob URLs don't allow query or fragment parts

RESOLVED FIXED in Firefox 44

Status

()

Core
DOM
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: Manuel Strehl, Assigned: baku)

Tracking

25 Branch
mozilla44
x86_64
Linux
Points:
---

Firefox Tracking Flags

(firefox44 fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131025151332

Steps to reproduce:

See this JSFiddle:

http://jsfiddle.net/boldewyn/vLNvA/

Create a new Blob, create its URL via window.URL.createObjectURL(), append a query, +'?foo=bar'. Use the URL, e.g. in window.open().


Actual results:

Error: Access to 'blob:91eb9c99-bf11-45aa-85a4-829157958d95?a' from script denied

and likewise for fragments.


Expected results:

The URI should have been loaded with query and fragment determined correctly.
(Reporter)

Comment 1

4 years ago
By the way, Firefox is already doing better than Chrome, where this problem also extends to data: URIs: https://code.google.com/p/chromium/issues/detail?id=123004

Comment 2

4 years ago
I tested with the latest Nightly, the testcase opens 2 tabs:
blob:ea657363-d482-46d8-95de-511e59a7739d
&
blob:ea657363-d482-46d8-95de-511e59a7739d#a (with the 1st line "Lorem" in yellow)

Is it the normal behavior?

If yes, could you install Nightly and confirm it's fixed on your side too, please.
http://nightly.mozilla.org/
Flags: needinfo?(bugzilla)
(Reporter)

Comment 3

4 years ago
No, not fully unfortunately. (Two out of three, to be precise.) I updated the description in the fiddle.

First tab is normal behaviour, works like a charm.

Second tab is missing: That's appending a query '?a' to the Blob URL. The console shows error "Access to blob denied".

Third tab in Nightly works now perfectly, too: fragment '#a' added to Blob URL, the CSS :target selector is activated.
Flags: needinfo?(bugzilla)

Comment 4

4 years ago
Thanks for the feedback.
It works partially in FF27+ due to bug 920877.

CC'ing devs about the remaining issue (Error: Access to 'blob:5c5ce277-be2a-4630-bcc9-4b4c79aa2a2e?a' from script denied).
Component: Untriaged → DOM
Depends on: 920877
Flags: needinfo?(phchang)
Product: Firefox → Core
That's the same error you'd get for any invalid blob: value, right?  As in, we tried to find a same-origin blob with that id and there isn't one...

Whether the value should be chopped off at '?' is the relevant question, I would think.
http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme
> A valid blob: URL must not have a query.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
(Reporter)

Comment 7

4 years ago
Interesting, thanks! Of course then the blob: “URI” is no URI in the sense of RFC 3986, which allows it explicitly in the generic case. That should be escalated as an upstream bug at W3C for the File API. (Let’s see, where I’ve put that W3C password...)
(Reporter)

Comment 8

4 years ago
Upstream bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23946
Flags: needinfo?(phchang)
Spec got changed.

Note that we need fragment support for SVG-in-a-blob.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---

Comment 10

2 years ago
Any update on this bug? I am still receiving an error for adding a query string to my blob url:

"Security Error: Content at http://mydomain.com may not load data from blob:http://mydomain.com/4632d7b7-eb78-41d5-b046-cdc1328229c9?type=mytype."

As stated By Boris, the specs changed and are no longer actively banning query strings.

Should their integration be considered?
It needs to be done, not considered.  The problem is finding someone with time to do it.

Andrea, do you have time for this?
Flags: needinfo?(amarchesini)
(Assignee)

Comment 12

2 years ago
Created attachment 8673635 [details] [diff] [review]
blob.patch
Flags: needinfo?(amarchesini)
Attachment #8673635 - Flags: review?(bzbarsky)
(Assignee)

Updated

2 years ago
Assignee: nobody → amarchesini
Comment on attachment 8673635 [details] [diff] [review]
blob.patch

>+  // Let's remove any fragment from this URI.

Well, fragment and query, right?

>+  nsAutoCString uriIgnoringFragment;

uriIgnoringFragmentAndQuery?

But also, I'm not sure we want this at all; see below.

>+  int32_t hasFragmentPos = aUri.FindChar('?');

No, the "fragment" is the thing that comes after the '#'.  The thing that comes after the '?' is the "query".  Please fix up the naming throughout as needed.

>+    pos = hasHashPos <= hasFragmentPos ? hasHashPos : hasFragmentPos;

Please use std::min.

>+  gDataTable->Get(uriIgnoringFragment, &res);

So... Get() takes, I believe, an nsACString.  So you could do:

  if (pos < 0) {
    gDataTable->Get(aUri, &res);
  } else {
    gDataTable->Get(StringHead(aUri, pos), &res);
  }

and probably save some string copies...

>+[test_blob_fragment.html]

test_blob_fragment_and_query.html, really.

r=me.  Thank you!
Attachment #8673635 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 14

2 years ago
Created attachment 8673879 [details] [diff] [review]
blob.patch
Attachment #8673635 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Keywords: checkin-needed

Comment 15

2 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/73f8f4985df4
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/73f8f4985df4
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago2 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in before you can comment on or make changes to this bug.