A Blob URL object's origin property should not be "null"

RESOLVED FIXED in Firefox 49

Status

()

defect
RESOLVED FIXED
3 years ago
a month ago

People

(Reporter: 446240525, Assigned: baku)

Tracking

({dev-doc-complete})

unspecified
mozilla49
Points:
---

Firefox Tracking Flags

(firefox49 fixed)

Details

(Whiteboard: [DocArea=DOM] btpp-followup-2016-05-12)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
> new URL("blob:http://foo.com/bar").origin
"null" // should be "http://foo.com"

see spec https://url.spec.whatwg.org/#origin
(Assignee)

Comment 1

3 years ago
Actually we return the correct origin if the blob has been generated from the page:

new URL(URL.createObjectURL(new Blob(['']))).origin => "https://bugzilla.mozilla.org"

I guess we should change the spec so that we return "null" in case the blob URL is not 'owned' by the page.
Flags: needinfo?(annevk)

Comment 2

3 years ago
So you'd want the algorithm that determines the origin to also do some global lookup to make sure the identifier is valid?
Flags: needinfo?(annevk)
(Assignee)

Comment 3

3 years ago
(In reply to Anne (:annevk) from comment #2)
> So you'd want the algorithm that determines the origin to also do some
> global lookup to make sure the identifier is valid?

Currently we retrieve the nsIPrincipal associated with the blob URL and we get the origin from that.
But if the blob URL doesn't have an underlying Blob object, we don't have any principal and we return "null".

Instead having a way to return a valid origin for an invalid blob, we should probably change the spec saying that: if the blob is unknown, origin should be "null".
Flags: needinfo?(annevk)
Whiteboard: [DocArea=DOM] → [DocArea=DOM] btpp-followup-2016-05-12

Comment 4

3 years ago
What is the problem with the model from the URL standard? It seems to work fine in Chrome. That is, the origin is embedded in the URL, and the full URL (minus blob scheme) is used as identifier, so you can't really change the origin since that'd make the identifier invalid.
Flags: needinfo?(annevk)
(Assignee)

Comment 5

3 years ago
Posted patch origin.patchSplinter Review
Assignee: nobody → amarchesini
Attachment #8750719 - Flags: review?(bugs)
Comment on attachment 8750719 [details] [diff] [review]
origin.patch

>@@ -5801,16 +5801,36 @@ nsContentUtils::GetUTFOrigin(nsIURI* aUR
>     if (principal) {
>       nsCOMPtr<nsIURI> uri;
>       nsresult rv = principal->GetURI(getter_AddRefs(uri));
>       NS_ENSURE_SUCCESS(rv, rv);
> 
>       if (uri && uri != aURI) {
>         return GetUTFOrigin(uri, aOrigin);
>       }
>+    } else {
>+      // We are probably dealing with an unknown blob.
blob url, not blob.

>+      bool isBlob = false;
isBlobURL
>+
>+        return GetUTFOrigin(uri, aOrigin);
...
>+  is ((new URL("blob:http://foo.com/bar")).origin, "http://foo.com");
>+  is ((new URL("blob:blob:http://foo.com/bar")).origin, "http://foo.com");
interesting, this is what the spec says.
Blink doesn't do this though.
Want to file a chromium bug?
Attachment #8750719 - Flags: review?(bugs) → review+
"opaque origin" is still vaguely defined in the spec. We seem to just return "null".
The spec says "..must return the Unicode serialization" ..."opaque origin" ... "An internal value, with no serialisation"
So it is not clear how a value with not serialization can be serialized.

But that is about some other bug, not about this one.

Comment 9

3 years ago
I just wanted to say that an opaque origin does not itself have a serialization, but a Unicode/ASCII serialization of it will give you "null". The reason that is not a serialization of an opaque origin, is that you cannot recreate the opaque origin from it.

I agree that is somewhat confusing. Should I just add a note?
(Assignee)

Comment 10

3 years ago
Yes, please. And if you think we should change something in our implementation, file a bug and CC/Assign it to me. Thanks a lot.

Comment 11

3 years ago
https://github.com/whatwg/html/pull/1245. I think our implementation is correct by the way. I'm not sure why Chrome continues to have bogus serialization like "blob://" for these. Probably not really on their radar.

Comment 12

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/9d4f4af7ca20
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49

Comment 14

3 years ago
I filed bug 1282504 to revert this per discussion in https://github.com/whatwg/url/issues/127.
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.