New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider removing `document.origin` #410

Open
mikewest opened this Issue Feb 15, 2017 · 26 comments

Comments

9 participants
@mikewest
Copy link
Member

mikewest commented Feb 15, 2017

We have self.origin in HTML, present inside workers and documents. It seems redundant and confusing to suggest that there's a different origin for documents than for the global object they host. Perhaps we can simply remove this in favor of the property on the global?

@bzbarsky seems to be on board with this notion. @cdumez, WDYT?

Edge hasn't implemented this yet, but perhaps @travisleithead has an opinion from a TAG/platformey perspective?

@cdumez

This comment has been minimized.

Copy link
Contributor

cdumez commented Feb 15, 2017

WebKit does not currently support self.origin but we will likely implement it in the future. Once we support self.origin, we can start deprecating document.origin in WebKit but I suspect it is going to be a while until we actually remove it (if ever, depending on how much it beaks existing content). That said, I do not have an objection if people want to drop document.origin from the spec, I just think it is a bit early given that self.origin is not well deployed yet.

Here are a few things that are not mentioned on this issue that would help decide:

  1. Who currently supports document.origin? I seem to remember it is only Blink and WebKit but someone should confirm.
  2. Who already ships self.origin? I suspect no one yet even though it is implemented in Firefox nightly iirc.
@bzbarsky

This comment has been minimized.

Copy link

bzbarsky commented Feb 15, 2017

Correct on both counts, as far as I know: document.origin is only in Blink and WebKit, but not interoperable between the two in shipped versions. self.origin is only in Firefox nightlies so far.

@mikewest

This comment has been minimized.

Copy link
Member Author

mikewest commented Feb 15, 2017

I just think it is a bit early given that self.origin is not well deployed yet.

I think we're just looking for feedback from other vendors at this point. If you're on board with the idea of migrating to self.origin, and can commit to the (hopefully minimal) work necessary to implement it at some point in the future, and send a console warning or something when you do, then I'm pretty sure we'll do the same in Blink. We're arguing about the impact of this a bit in https://groups.google.com/a/chromium.org/d/msg/blink-dev/CO52Bt15cuc/ya6u_devCQAJ if you'd like to skim through and add your thoughts.

To your questions:

  1. Only Blink and WebKit (and, really, only WebKit nightly after your recent fix: you could, for instance, drop that entirely rather than keeping the broken implementation, right?)

  2. Firefox nightly is it. We'll have a patch for Blink tomorrowish, but it won't hit stable for a few weeks.

@cdumez

This comment has been minimized.

Copy link
Contributor

cdumez commented Feb 15, 2017

Sure, I can commit to implementing self.origin in WebKit in the relatively short-term, given that other browsers are already implementing it and I like the idea.

I also do not object to dropping document.origin from the spec given that this is a Blink/WebKit thing only and there is a better alternative available.

@domenic

This comment has been minimized.

Copy link
Member

domenic commented Jul 14, 2017

As predicted the use counter in Blink is around ~0.09%: https://www.chromestatus.com/metrics/feature/timeline/popularity/1828 But we have no idea how much of that is just enumeration of the document's properties.

@mikewest, what's our next move?

@cdumez

This comment has been minimized.

Copy link
Contributor

cdumez commented Aug 8, 2017

If we remove document.origin, am I right that developers will have no way of setting the document's origin via JS? I believe self.origin is readonly while document.origin is not.

@bzbarsky

This comment has been minimized.

Copy link

bzbarsky commented Aug 8, 2017

document.origin is readonly. See https://dom.spec.whatwg.org/#document

Maybe you were thinking about document.domain, which is a totally different thing?

@mikewest

This comment has been minimized.

Copy link
Member Author

mikewest commented Aug 9, 2017

Yeah. The numbers are higher than I'd hoped. I think there's a reasonable argument to be made that until Safari's change actually hits users (with Safari 11, I imagine?), that these pages are actually broken. @cdumez, it looks like self.origin is in ToT (https://github.com/WebKit/webkit/blob/39765fd9f55c0268bef9d887fc8b8cb0edf5f64b/Source/WebCore/page/WindowOrWorkerGlobalScope.idl#L31); do you happen to know if it landed in time to make the cut for Safari 11?

If so, then it seems reasonable to try for deprecation.

@cdumez

This comment has been minimized.

Copy link
Contributor

cdumez commented Aug 9, 2017

Oh I was thinking of document.domain, sorry.

@cdumez

This comment has been minimized.

Copy link
Contributor

cdumez commented Aug 9, 2017

Self.origin is in Safari 11, yes.

@dstorey

This comment has been minimized.

Copy link
Member

dstorey commented Dec 15, 2017

Is there any update here? We (Edge) have to decide if we're going to implement this or not. We're currently working on the other missing features.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Dec 15, 2017

I think we would have liked that, but judging from the spike to 0.75% in https://www.chromestatus.com/metrics/feature/timeline/popularity/1828 it seems like it might be way too late.

Given #410 (comment) we probably need to add some more tests for document.origin to ensure that it at least becomes interoperable.

@bzbarsky

This comment has been minimized.

Copy link

bzbarsky commented Dec 20, 2017

What do the uses look like? If it's document.origin || self.origin that could explain a spike while also allowing removal... The fact that Edge and Gecko don't implement and it hasn't been an obvious compat problem makes me a bit wary of assuming things about the data here.

@travisleithead

This comment has been minimized.

Copy link

travisleithead commented Jan 10, 2018

Chatted with @dstorey and we think we can help the situation out by not implementing document.origin and instead getting self.origin implemented in an upcoming release. We're not seeing the compat pain (yet?) for document.origin, so we can try to hold-out as long as possible on that front.

@dstorey

This comment has been minimized.

Copy link
Member

dstorey commented Jan 12, 2018

To summarise:

  • Gecko, Blink, and WebKit support self.origin, while Edge plans to do so in a future release
  • WebKit and Blink support document.origin but they're not interoperable
  • Edge and Gecko have so far not seen any interop pain from not supporting document.origin
  • Edge has no plans to support it unless we see interop pain in the future
  • Having both self.origin and document.origin could be seen as redundant/confusing

Considering the above I'd propose we:

  • remove document.origin from the spec or move it into a deprecated partial
  • add deprecated messages to the console in Blink and Webkit pointing to self.origin
@annevk

This comment has been minimized.

Copy link
Member

annevk commented Jan 12, 2018

@foolip @RByers @cdumez your feedback on the above proposal would be appreciated!

@annevk annevk added the interop label Jan 12, 2018

@cdumez

This comment has been minimized.

Copy link
Contributor

cdumez commented Jan 12, 2018

Proposal sounds fine to me.

@RByers

This comment has been minimized.

Copy link
Contributor

RByers commented Jan 12, 2018

Sounds reasonable to me, but someone will need to do the analysis to come up with a concrete deprecation plan according to our compat principles. We don't add deprecation messages without an approved removal timeframe anymore. But given the existing lack of interop, I suspect this may be as simple as showing some evidence that removal is unlikely to cause observable breakage (eg. spot check a handful of sites we find via HTTP archive) and giving removal a try. @mikewest perhaps you or someone on your team could do this?

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Mar 13, 2018

@foolip can you help with this? I'm happy to help with tests and the specification.

@dstorey

This comment has been minimized.

Copy link
Member

dstorey commented Mar 16, 2018

Update: origin on WorkerGlobalScope and Window is now in code review. Will be in some future version of Edge (probably 18)

@foolip

This comment has been minimized.

Copy link
Member

foolip commented Apr 16, 2018

Looks like we already had an Intent to Deprecate: document.origin on blink-dev.

@foolip

This comment has been minimized.

@foolip

This comment has been minimized.

Copy link
Member

foolip commented Apr 16, 2018

The results of a fresh search for "document.origin" is in document_origin.json. I used unjson to split it into 2419 files. I split those into different buckets to try to filter out the harmless stuff. The result I've uploaded as https://storage.googleapis.com/blink-httparchive-export/document_origin.tgz.

Almost all (2205) fall into the false-positives, fingerprinting, and not-broken buckets.

In the maybe-broken bucket there's these sites that could throw an exception if document.origin isn't there and I can reach the code path in Chrome:
http://www.amebaownd.com/
http://www.aromaspace-japan.tokyo/
http://www.brandnewidolsociety.tokyo/
http://www.hiroyuki.com/
http://www.hi-vision.net/
http://www.mienoko.jp/
http://www.yuqinakamura.jp/

But they still seem to work fine in Firefox, can't see what's broken, if anything.

Also in the maybe-broken bucket is a bunch of sites that include https://assets.pscp.tv/univ/main-da74a29ac84387feaee6.js, including http://www.pscp.tv/ itself. It has this event handler:

window.addEventListener("message", function(t) {
    var n = t.origin || t.originalEvent.origin === document.origin
        , r = t.source === e.popup;
    n && r && e.props.onMessage && e.props.onMessage({
        message: t.data
    })
})

But I can't reach that code path in Chrome, not sure what it takes.

There are 80 hits that didn't fall into a bucket and would need individual checking. I checked a few and couldn't find any breakage and nothing that screamed "this will break" on the same lines in grep. Still, some might be affected: (not checked/filtered for porn, which often shows up in these anlyses)
http://aktuelnaturvidenskab.dk/
http://cs.au.dk/
http://www.ab.gr/
http://www.adbug.cn/
http://www.adexchanger.cn/
http://www.adme.ru/
http://www.ascc2017.com/
http://www.attendstar.com/
http://www.au.dk/
http://www.avito.ru/
http://www.avito.ru/
http://www.avito.st/
http://www.avito.st/
http://www.bikeworld.pl/
http://www.brightside.me/
http://www.cargotec.com/
http://www.cassidytravel.ie/
http://www.codio.com/
http://www.delhaize.be/
http://www.devdocs.io/
http://www.ellechina.com/
http://www.fiverr.com/
http://www.fiverr.co.uk/
http://www.fivver.com/
http://www.genial.guru/
http://www.glamsquad.com/
http://www.griffith.edu.au/
http://www.hackster.io/
http://www.haiwai.com/
http://www.hermo.my/
http://www.heroic.academy/
http://www.hijup.com/
http://www.incrivel.club/
http://www.irishlife.ie/
http://www.jackrogersusa.com/
http://www.kadenze.com/
http://www.lariojaturismo.com/
http://www.learnnext.com/
http://www.letsrecap.com/
http://www.likemtr.ru/
http://www.loandepot.com/
http://www.magisto.com/
http://www.mgen.fr/
http://www.multisim.com/
http://www.newslaundry.com/
http://www.nextgurukul.in/
http://www.olx.ru/
http://www.olx.ru/
http://www.pigeonhole.at/
http://www.plumbnation.co.uk/
http://www.promovacances.com/
http://www.pymex.pe/
http://www.reacttraining.com/
http://www.slando.ru/
http://www.slando.ru/
http://www.sparks-lab.org/
http://www.sympa-sympa.com/
http://www.trendwatching.com/
http://www.trustscam.es/
http://www.turfomania.fr/
http://www.universalorlando.com/
http://www.whistler.com/
http://www.yves-rocher.cz/
http://www.yves-rocher.ro/

Noteworthy is that on http://www.ing.com.au/ there's traces of a web developer wasting time because of this interop issue, with a comment saying "document.origin is not by ie":

function InterestRateManager() {
        //document.origin is not by ie
        this.serviceUrl = location.protocol + '//' + location.host + "/ReverseProxy/ProductService/V1/productservice.svc/json/interestrates/
currenteffective";

That's it. To me it seems like we should try to deprecate an remove this, because neither I nor @mikewest could find something that would break badly, and I found evidence of web developers being bitten by the interop problem.

@foolip

This comment has been minimized.

Copy link
Member

foolip commented Apr 16, 2018

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Jun 6, 2018

Based on discussion in whatwg/html#2697 I think we should also remove document's origin concept, alongside the attribute. All the security checks we have are about origins of globals, not of documents.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Jun 6, 2018

(Removing the concept might be harder than I thought, there's a fair number of dependencies on it at the moment that would have to be revamped. See also whatwg/html#2697 (comment).)

foolip added a commit to web-platform-tests/wpt that referenced this issue Aug 9, 2018

mikewest added a commit to web-platform-tests/wpt that referenced this issue Aug 9, 2018

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Aug 15, 2018

Bug 1482083 [wpt PR 12377] - Replace document.origin with self.origin…
… in cookie-helper.sub.js, a=testonly

Automatic update from web-platform-testsReplace document.origin with self.origin in cookie-helper.sub.js (#12377)

In anticipation of whatwg/dom#410
--

wpt-commits: 0e1ac363581d4bf0851a00a5563619bfef622fe4
wpt-pr: 12377

jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Aug 15, 2018

Bug 1482083 [wpt PR 12377] - Replace document.origin with self.origin…
… in cookie-helper.sub.js, a=testonly

Automatic update from web-platform-testsReplace document.origin with self.origin in cookie-helper.sub.js (#12377)

In anticipation of whatwg/dom#410
--

wpt-commits: 0e1ac363581d4bf0851a00a5563619bfef622fe4
wpt-pr: 12377
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment