Intent to implement and ship: document.origin

[Boris Zbarsky]

Summary: document.origin returns the Unicode serialization of the
document's origin. The returned value does not depend on what
document.domain was set to.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884

Spec: http://dom.spec.whatwg.org/#dom-document-origin

Platform coverage: All of them.

Estimated release: 37

I don't plan to put this behind a pref. It's trivial to back out if
need be.

Blink is considering implementing this too, and they're trying to find
out whether we plan to implement. I think this is a useful feature and
we should add it.

The only caveat is possible confusion due to the difference between
document.origin and location.origin; I'm a bit torn about what to do
about that, if anything, short of removing location.origin....

-Boris

[Mounir Lamouri]

On Tue, 2 Dec 2014, at 02:09, Boris Zbarsky wrote:
> Summary: document.origin returns the Unicode serialization of the
> document's origin. The returned value does not depend on what
> document.domain was set to.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884
>
> Spec: http://dom.spec.whatwg.org/#dom-document-origin
>
> Platform coverage: All of them.
>
> Estimated release: 37
>
> I don't plan to put this behind a pref. It's trivial to back out if
> need be.
>
> Blink is considering implementing this too, and they're trying to find
> out whether we plan to implement. I think this is a useful feature and
> we should add it.

For those interested.

Blink patch:
https://codereview.chromium.org/758913002

... and blink-dev discussion:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/8aDWaY9b3BM/sb77MikxNncJ

-- Mounir

[Kevin Grandon]

We currently use location.origin quite frequently in gaia, and we also use it in workers. My vote would be to keep it around, especially if we have no way of getting document.origin from a worker.

The naming is a bit confusing to me as a web developer. Not sure if it's possible, but at first glance something like `location.documentOrigin` would make more sense to me - then we could use it in workers I assume?

Best,
Kevin

----- Original Message -----
From: "Mounir Lamouri" <mou...@lamouri.fr>
To: dev-pl...@lists.mozilla.org
Sent: Tuesday, December 2, 2014 3:43:08 AM
Subject: Re: Intent to implement and ship: document.origin

On Tue, 2 Dec 2014, at 02:09, Boris Zbarsky wrote:

> Summary: document.origin returns the Unicode serialization of the
> document's origin. The returned value does not depend on what
> document.domain was set to.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884
>
> Spec: http://dom.spec.whatwg.org/#dom-document-origin
>
> Platform coverage: All of them.
>
> Estimated release: 37
>
> I don't plan to put this behind a pref. It's trivial to back out if
> need be.
>
> Blink is considering implementing this too, and they're trying to find
> out whether we plan to implement. I think this is a useful feature and
> we should add it.

For those interested.

Blink patch:
https://codereview.chromium.org/758913002

... and blink-dev discussion:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/8aDWaY9b3BM/sb77MikxNncJ

-- Mounir

_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Boris Zbarsky]

On 12/2/14, 8:17 AM, Kevin Grandon wrote:
> We currently use location.origin quite frequently in gaia, and we also use it in workers.

So the difference between location.origin and document.origin is that
the latter is the origin of the document and the former is the origin of
the document's URI.

For example, if you have an about:blank iframe, or an <iframe srcdoc>
then location.origin will be "null" but document.origin will be the
origin of the document involved (which is the same as the origin of the
parent document).

location.origin in workers has the same problem: it's the origin of the
URI the worker was loaded from, not the origin of the worker. For example:

var w =
new Worker('data:text/javascript,postMessage(location.origin)');
w.onmessage = function(e) { alert(e.data); }

will alert "null".

> My vote would be to keep it around, especially if we have no way of getting document.origin from a worker.

Are you trying to get the origin of the worker, the origin of the
document that started the worker (at the moment, more or less the same
thing, but maybe not into the future), the origin of the URI the worker
was loaded from (what location.origin does right now) or something else?

> The naming is a bit confusing to me as a web developer.

Yes. I suspect that location.origin is mostly a footgun both in workers
and in Window contexts...

> Not sure if it's possible, but at first glance something like `location.documentOrigin` would make more sense to me

It's possible, but I don't think it's a good idea. First of all, for
which document? The one the location is from or the current document in
the browsing context (like most location stuff)?

>- then we could use it in workers I assume?

We can add an API to workers to get origins, if we know which origins
we're interested in. We should not be putting it on Location, in my
opinion.

But I agree there is value in doing this in a way that acts the same in
windows and workers. Perhaps what we should really do is put .origin on
Window and on WorkerGlobalScope instead of (or in addition to?) putting
it on Document? Then "self.origin" would do the right thing in both a
Window and a worker... But it does involve adding "origin" in the global
scope.

-Boris

[Jonas Sicking]

On Dec 2, 2014 1:41 PM, "Boris Zbarsky" <bzba...@mit.edu> wrote:
>
> On 12/2/14, 8:17 AM, Kevin Grandon wrote:
>>
>> We currently use location.origin quite frequently in gaia, and we also
use it in workers.
>
>
> So the difference between location.origin and document.origin is that the
latter is the origin of the document and the former is the origin of the
document's URI.

This difference seems really esoteric to me. Do we really expect developers
to understand this difference and use the right one? Especially given the
very similar names?

Are there use cases for both?

I definitely think that JS in workers will generally have the same needs as
JS in Windows. So we need to figure out how to expose whatever we expose on
Documents to Worker contexts as well.

/ Jonas

[Boris Zbarsky]

On 12/3/14, 2:28 AM, Jonas Sicking wrote:
> This difference seems really esoteric to me. Do we really expect developers
> to understand this difference and use the right one? Especially given the
> very similar names?

I don't. Hence my proposal to remove location.origin.

> Are there use cases for both?

I can't think of sane use cases for location.origin. Afaict the only
reason it's on there is that all URLUtils things have a .origin...

-Boris

[Anne van Kesteren]

On Wed, Dec 3, 2014 at 11:50 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> I can't think of sane use cases for location.origin. Afaict the only reason
> it's on there is that all URLUtils things have a .origin...

Correct. I thought that was added a long time ago. Anyway, the
difference between a document's origin and a document's browsing
context's active document's associated URL's origin is pretty big.

On blink-dev I recommended we move ahead with document.origin and add
self.origin in workers per
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27497 (not yet fixed).


--
https://annevankesteren.nl/

[Martin Thomson]

> On 2014-12-03, at 02:50, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> I can't think of sane use cases for location.origin. Afaict the only reason it's on there is that all URLUtils things have a .origin...

I think that you will find that there are a few uses of location.origin already. I’m willing to bet that document/window.origin was what was intended.

[Boris Zbarsky]

On 12/3/14, 6:30 AM, Anne van Kesteren wrote:
> Correct. I thought that was added a long time ago.

location.origin has existed in Firefox since Firefox 21, I guess (and
Firefox 29 for Workers). I guess that does make it hard to remove.
That sucks. :(

> Anyway, the difference between a document's origin and a document's browsing
> context's active document's associated URL's origin is pretty big.

Indeed. Bringing us back to "why would someone ever care about the latter?"

-Boris

[Anne van Kesteren]

On Wed, Dec 3, 2014 at 7:58 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> Indeed. Bringing us back to "why would someone ever care about the latter?"

I don't think you should use that unless you want to know the origin
of the URL of the corresponding href in question. E.g. similar to why
you might want to inspect <a>.origin. I realize that people use
Location objects for all sorts of things that might be wrong, I don't
have a good solution to that other than that we should not build more
on top of it. Location is fundamentally a broken object, due to it
representing a document's browsing context's active document.


--
https://annevankesteren.nl/

[Jonas Sicking]

Pinging this old thread since nothing seems to have happened since it
was last discussed.

My recommendation is still to make location.origin return the "origin
of the document" rather than "the origin of the URL". I would be
surprised if that didn't fix many more pages than it broke.

I think making the location object match URLUtils is futile. There's
so much weirdness about the location object that I think we should
treat it as the special flower that it is.

That would also make the origin available to workers.

I don't have a strong opinion on if we also implement document.origin or not.

/ Jonas


On Wed, Dec 3, 2014 at 9:02 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Wed, Dec 3, 2014 at 7:58 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
>> Indeed. Bringing us back to "why would someone ever care about the latter?"
>

> I don't think you should use that unless you want to know the origin
> of the URL of the corresponding href in question. E.g. similar to why
> you might want to inspect <a>.origin. I realize that people use
> Location objects for all sorts of things that might be wrong, I don't
> have a good solution to that other than that we should not build more
> on top of it. Location is fundamentally a broken object, due to it

> representing a document's browsing context's active document.
>
>
> --
> https://annevankesteren.nl/

[Anne van Kesteren]

On Wed, Mar 18, 2015 at 1:09 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> I think making the location object match URLUtils is futile. There's
> so much weirdness about the location object that I think we should
> treat it as the special flower that it is.

Other than the location object tracking a URL you might not expect
there's not that much weirdness. I think it would be weird if the
invariants that hold for <a> and new URL() don't hold for Location.


--
https://annevankesteren.nl/

[Boris Zbarsky]

On 3/18/15 2:39 AM, Anne van Kesteren wrote:
> On Wed, Mar 18, 2015 at 1:09 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>> I think making the location object match URLUtils is futile. There's
>> so much weirdness about the location object that I think we should
>> treat it as the special flower that it is.
>
> Other than the location object tracking a URL you might not expect

And not having .searchParams. And having weird non-local side-effects
on set (like blowing away your entire global). And the fact that your
getters and most of your setters might suddenly start throwing when you
least expect them to.

I seem to recall thre was some other weirdness that I can't recall right
now too.

> I think it would be weird if the
> invariants that hold for <a> and new URL() don't hold for Location.

That's already the case for tons of invariants.

-Boris

[Anne van Kesteren]

On Wed, Mar 18, 2015 at 2:18 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 3/18/15 2:39 AM, Anne van Kesteren wrote:
>> Other than the location object tracking a URL you might not expect
>
> And not having .searchParams.

That is in our implementation and still an outstanding issue in the
specification.

> And having weird non-local side-effects on
> set (like blowing away your entire global).

Sure, aka HTML's navigate.

> And the fact that your getters
> and most of your setters might suddenly start throwing when you least expect
> them to.

Is that defined?

> I seem to recall thre was some other weirdness that I can't recall right now
> too.



>> I think it would be weird if the
>> invariants that hold for <a> and new URL() don't hold for Location.
>
> That's already the case for tons of invariants.

I don't think so. The various component attributes all return what you'd expect.


Also, https://code.google.com/p/chromium/issues/detail?id=436377 was
committed a while back.


--
https://annevankesteren.nl/

[Jonas Sicking]

>>> I think it would be weird if the
>>> invariants that hold for <a> and new URL() don't hold for Location.
>>
>> That's already the case for tons of invariants.
>

> I don't think so. The various component attributes all return what you'd expect.

I still think the value added by making window.location be consistent
with the URL object, is much smaller than making
window.location.origin be a logical and useful value.

/ Jonas

[Boris Zbarsky]

On 3/19/15 3:16 AM, Anne van Kesteren wrote:
> That is in our implementation

Yes, because it was a security bug as specified, iirc.

Of course no one else implements searchParams at all, or plans to.

But as long as we're talking implementations, last I checked no one else
even implemented URLUtils on Location. For example, Chrome and Safari
have .username/.password on URL but not on Location.

> and still an outstanding issue in the
> specification.

Yes...

>> And the fact that your getters
>> and most of your setters might suddenly start throwing when you least expect
>> them to.
>
> Is that defined?

Sure. You have a Location object, the corresponding navigation context
is navigated cross-origin, suddenly most of your accessors (but not all)
are dead in the water.

> I don't think so. The various component attributes all return what you'd expect.

Not in implementations; see above.

> Also, https://code.google.com/p/chromium/issues/detail?id=436377 was
> committed a while back.

Mmm, lovely.

-Boris

[Boris Zbarsky]

I would like to revive this intent. At this point estimated release
would be 54, and Blink has shipped this a while ago.

The state of things here is as follows:

1) location.origin still exists and sites use it, so we can't remove
it. But we can deprecate it if we want.

2) document.origin is in the spec and shipping in Safari and Chrome.
Except the Safari version doesn't match the spec at all...
https://bugs.webkit.org/show_bug.cgi?id=168022 filed. Edge 14 doesn't
seem to support this; I don't know about their developer preview.

3) The spec also defines self.origin (in both workers and windows, for
consistent API). For the window case it returns the origin of the
active document. No one else implements this yet; I will be sending a
separate intent for this.

-Boris

[Mike West]

Perhaps we could deprecate `document.origin` and ship `self.origin` in
Blink instead of y'all shipping `document.origin`? It seems like we want to
encourage folks to use `self.origin` going forward...

-mike

[Boris Zbarsky]

On 2/9/17 5:44 AM, Mike West wrote:
> Perhaps we could deprecate `document.origin` and ship `self.origin` in
> Blink instead of y'all shipping `document.origin`?

Given the lack of support in Edge and the incompatible support in
WebKit, I can probably live with that. Especially if y'all remove it in
a reasonably short timeframe. ;)

> It seems like we want to encourage folks to use `self.origin` going forward...

I agree.

-Boris

[Boris Zbarsky]

On 2/9/17 5:44 AM, Mike West wrote:

> Perhaps we could deprecate `document.origin` and ship `self.origin` in
> Blink instead of y'all shipping `document.origin`? It seems like we want to
> encourage folks to use `self.origin` going forward...

So specifically, should I be asking Anne to remove document.origin from
the spec?

-Boris