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

Status: RESOLVED FIXED

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

Description

[ziyunfei]

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

see spec https://url.spec.whatwg.org/#origin

Comment 1

[Andrea Marchesini [:baku]]

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.

Comment 2

[Anne (:annevk)]

So you'd want the algorithm that determines the origin to also do some global lookup to make sure the identifier is valid?

Comment 3

[Andrea Marchesini [:baku]]

(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".

Comment 4

[Anne (:annevk)]

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.

Comment 5

[Andrea Marchesini [:baku]]

Attachment: origin.patch

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

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?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

"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 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9d4f4af7ca20

Comment 9

[Anne (:annevk)]

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?

Comment 10

[Andrea Marchesini [:baku]]

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

[Anne (:annevk)]

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

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/9d4f4af7ca20

Comment 13

[Jean-Yves Perrier [:teoli]]

Updated description in:
https://developer.mozilla.org/en-US/docs/Web/API/URL/origin
and
https://developer.mozilla.org/en-US/docs/Web/API/HTMLHyperlinkElementUtils

and a comment in:
https://developer.mozilla.org/en-US/Firefox/Releases/49#DOM_HTML_DOM

Comment 14

[Anne (:annevk)]

I filed bug 1282504 to revert this per discussion in https://github.com/whatwg/url/issues/127.