Closed Bug 1270451 Opened 7 years ago Closed 7 years ago

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


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

Not set



Tracking Status
firefox49 --- fixed


(Reporter: 446240525, Assigned: baku)



(Keywords: dev-doc-complete, Whiteboard: [DocArea=DOM] btpp-followup-2016-05-12)


(1 file)

> new URL("blob:").origin
"null" // should be ""

see spec
Actually we return the correct origin if the blob has been generated from the page:

new URL(URL.createObjectURL(new Blob(['']))).origin => ""

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)
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)
(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
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)
Attached patch origin.patchSplinter Review
Assignee: nobody → amarchesini
Attachment #8750719 - Flags: review?(bugs)
Comment on attachment 8750719 [details] [diff] [review]

>@@ -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;
>+        return GetUTFOrigin(uri, aOrigin);
>+  is ((new URL("blob:")).origin, "");
>+  is ((new URL("blob:blob:")).origin, "");
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.
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?
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. 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.
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
I filed bug 1282504 to revert this per discussion in
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.