Intent to Deprecate: `document.origin`

[Mike]

Primary eng (and PM) emails

mk...@chromium.org

Summary

I intend to deprecate (and eventually remove) the `origin` property on `Document` objects.

Motivation

We've implemented a similar property on the global object: `self.origin`. Given that, the `origin` property on `Document` objects is a wart we should be able to remove in order to reduce developer confusion.

Compatibility And Interoperability Risk

Safari ships this API.

Edge does not.

Firefox does not.

Alternative implementation suggestion for web developers

The origin property on the global object is a complete replacement for `document.origin`, and has the advantage of working in both documents and workers.

Usage information from UseCounter

We don't yet have usage data. I intend to collect this data by deprecating the feature, and we can make a decision about removal when we have some data to go on. Given that it's not implemented in Edge or Firefox, I expect usage to be low.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=692084

Entry on the feature dashboard

https://www.chromestatus.com/feature/5701042356355072

Requesting approval to remove too?

No, but I'd aim for ~59ish if the numbers look reasonable.

-mike

[Boris Zbarsky]

On 2/14/17 10:15 AM, Mike wrote:
> Compatibility And Interoperability Risk
>
> Safari ships this API.

Though note that the values in shipping Safari don't match Blink's
(returns "https_webkit.org_0" instead of "https://webkit.org", for
example). But they just changed that in webkit tip. See
https://bugs.webkit.org/show_bug.cgi?id=168022

So the interop risk is a bit lower than if they were already shipping a
compatible version.

-Boris

[Jochen Eisinger]

LGTM to deprecate

[Chris Harrelson]

I don't think we should deprecate without data supporting our ability to remove it. Let's get UseCounter data first.

LGTM to deprecate

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

Given that this is an attribute on document, a use counter will almost certainly be inflated beyond the point of being useful. An analysis of 'document.origin' matches from httparchive might tell us immediately if removal is going to be safe. There are only a couple of hundred results, which in itself is promising.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

That's a good point that the UseCounter would be inflated. Someone should post the explicit httparchive data here as a replacement though, plus perhaps a github search or other data points.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

https://storage.googleapis.com/blink-httparchive-export/document.origin.json is an export of the 197 results. Feel like taking a look, Mike?

(In https://github.com/foolip/unhar/blob/master/unjson I have a script I use for these things, but it's missing the step to actually split files like this by line. Splitting document.origin.json by line into separate files first should make it usable though.)

On Wed, Feb 15, 2017 at 12:14 AM Chris Harrelson <chri...@chromium.org> wrote:

That's a good point that the UseCounter would be inflated. Someone should post the explicit httparchive data here as a replacement though, plus perhaps a github search or other data points.

On Tue, Feb 14, 2017 at 9:07 AM, Philip Jägenstedt <foo...@chromium.org> wrote:

Given that this is an attribute on document, a use counter will almost certainly be inflated beyond the point of being useful. An analysis of 'document.origin' matches from httparchive might tell us immediately if removal is going to be safe. There are only a couple of hundred results, which in itself is promising.

On Wed, Feb 15, 2017 at 12:03 AM Chris Harrelson <chri...@chromium.org> wrote:

I don't think we should deprecate without data supporting our ability to remove it. Let's get UseCounter data first.

On Tue, Feb 14, 2017 at 8:25 AM, Jochen Eisinger <joc...@chromium.org> wrote:

LGTM to deprecate

Boris Zbarsky <bzba...@mit.edu> schrieb am Di., 14. Feb. 2017, 17:09:

On 2/14/17 10:15 AM, Mike wrote:
> Compatibility And Interoperability Risk
>
> Safari ships this API.

Though note that the values in shipping Safari don't match Blink's
(returns "https_webkit.org_0" instead of "https://webkit.org", for
example).  But they just changed that in webkit tip.  See
https://bugs.webkit.org/show_bug.cgi?id=168022

So the interop risk is a bit lower than if they were already shipping a
compatible version.

-Boris

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

I got 169 results with [1]. Of those:

* 80 were a library from `periscope.tv`

* 44 were a library from `spamanalyst.com`

The other 45 look like more or less legit usage.  I'm hopeful that deprecating the attribute and pointing to the drop-in replacement (literally `s/document.origin/self.origin/`) will be effective. I'd like to try that.

[1]: ```

SELECT

  *

FROM (

  SELECT

    page,

    url,

    REGEXP_EXTRACT(body, r'(.{0,50}document\.origin)\W') as match

  FROM 

    [httparchive:har.2017_01_01_chrome_requests_bodies]

) WHERE

  match != "null"

```

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Elliott Sprehn]

If the use counter is going to be "so inflated that it can't be useful" I assume from folks iterating the document properties, doesn't that mean deprecating it would spam all those users too?

It seems unfortunate to break the process here. We shouldn't add console warnings without knowing how many users were going to spam with it. This doesn't seen urgent, I'd prefer we used the normal deprecation process.

[Mike]

On Tuesday, February 14, 2017 at 10:33:03 PM UTC+1, Elliott Sprehn wrote:

If the use counter is going to be "so inflated that it can't be useful" I assume from folks iterating the document properties, doesn't that mean deprecating it would spam all those users too?

I recognize the concern around spamming developers. That said, if we allow that to be an overriding concern, then I don't see how we can ever deprecate anything on `document` or `self`, which seems unfortunate. :)

It seems unfortunate to break the process here. We shouldn't add console warnings without knowing how many users were going to spam with it.

Break the process? "Intent to deprecate" is the process, isn't it? The template suggests as much: "'No' means you will be showing a deprecation warning and counting feature usage with the intent of removing support.  Please indicate the milestone you intend to remove the API by (which should be included in the deprecation message)."

 

This doesn't seen urgent, I'd prefer we used the normal deprecation process.

Boris has identified this as an area where Mozilla is taking a compatibility hit. Given that they've just landed `self.origin`, and we're about to do the same, I think we have a window of opportunity to shift folks off the document-specific API. If we decide not to deprecate now, then I expect Mozilla would ship the property, and we'd end up locked in. Perhaps Boris can weigh in on that from his perspective?

Since Edge and Mozilla don't implement the `document.origin` property, and spot-checking the largest users of the property shows that they're checking whether it exists first), perhaps we can just remove it?

If we went that route, would we be able to add a deprecation message for a property we've removed? I remember this coming up in a previous thread, but I can't find it now...

-mike

[Philip Jägenstedt]

Yes, deprecations for attributes on at least window, document and event are spammy, but apparently not equally so. https://www.chromestatus.com/metrics/feature/timeline/popularity/116 is the document attribute with the lowest usage I can find, bounding spaminess of document to around 0.01%. Too high to ever say that something is trivially safe to remove, but not so high that we should skip (time-limited) deprecation entirely probably.

2017_01_01_chrome_pages has about 500k pages, and from Mike's analysis it sounds like ~0.01% (assuming most pages had just one resource with a match) are using document.origin in some useful, legitimate way. But, they also can't be working in Edge and Firefox currently, so hard breakage is unlikely. Mike, can find a representative example of how it's used?

I commented in https://bugs.webkit.org/show_bug.cgi?id=115643#c14 but then noticed that https://dom.spec.whatwg.org/#interface-document still as the origin attribute. Maybe file a spec issue for its removal to get WebKit feedback?

Aside: Where is self.origin implemented? Blink doesn't have the WindowOrWorkerGlobalScope mixin.

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Boris Zbarsky]

On 2/15/17 1:33 AM, Mike wrote:
> Boris has identified this as an area where Mozilla is taking a
> compatibility hit

> <https://twitter.com/bz_moz/status/831518483586375681>.

More precisely, is likely to end up with a compatibility hit, especially
if/when Safari ships a version that matches Chrome's.

My plan was to just add support for self.origin _and_ document.origin,
until Mike said he'd like to remove the latter from Blink. The amount
of implementation work is obviously tiny; the wart on the web platform
is annoying but not fatal. The risk of compat issues is high enough
that I did not feel it worthwhile to push for document.origin being
removed, which is why it's still in the spec...

I'm willing to wait some limited amount of time if Blink would prefer to
remove document.origin. I'm just not willing to wait forever. Been
burned by that a few times now... How long we can wait partly depends
on whether anyone is really using the property, of course; the less it's
used the longer we can wait (but the less need there is to wait,
obviously; if no one is using it, you can remove it more easily).

-Boris

[Elliott Sprehn]

On Tue, Feb 14, 2017 at 10:33 PM, Mike <mk...@chromium.org> wrote:

On Tuesday, February 14, 2017 at 10:33:03 PM UTC+1, Elliott Sprehn wrote:

If the use counter is going to be "so inflated that it can't be useful" I assume from folks iterating the document properties, doesn't that mean deprecating it would spam all those users too?

I recognize the concern around spamming developers. That said, if we allow that to be an overriding concern, then I don't see how we can ever deprecate anything on `document` or `self`, which seems unfortunate. :)

It seems unfortunate to break the process here. We shouldn't add console warnings without knowing how many users were going to spam with it.

Break the process? "Intent to deprecate" is the process, isn't it? The template suggests as much: "'No' means you will be showing a deprecation warning and counting feature usage with the intent of removing support.  Please indicate the milestone you intend to remove the API by (which should be included in the deprecation message)."

You sent an Intent to Deprecate without having done any measurement of how spammy it would be. I don't think it's reasonable to make a go/no go assessment on a deprecation without having done the measurement first. Adding a UseCounter is the usual process I was referring to.

Also your query to httparchive seems to look for document.origin, but lots of code is minified. How common is ".origin" ?

[Philip Jägenstedt]

On Thu, Feb 16, 2017 at 7:58 AM Elliott Sprehn <esp...@chromium.org> wrote:

On Tue, Feb 14, 2017 at 10:33 PM, Mike <mk...@chromium.org> wrote:

On Tuesday, February 14, 2017 at 10:33:03 PM UTC+1, Elliott Sprehn wrote:

If the use counter is going to be "so inflated that it can't be useful" I assume from folks iterating the document properties, doesn't that mean deprecating it would spam all those users too?

I recognize the concern around spamming developers. That said, if we allow that to be an overriding concern, then I don't see how we can ever deprecate anything on `document` or `self`, which seems unfortunate. :)

It seems unfortunate to break the process here. We shouldn't add console warnings without knowing how many users were going to spam with it.

Break the process? "Intent to deprecate" is the process, isn't it? The template suggests as much: "'No' means you will be showing a deprecation warning and counting feature usage with the intent of removing support.  Please indicate the milestone you intend to remove the API by (which should be included in the deprecation message)."

You sent an Intent to Deprecate without having done any measurement of how spammy it would be. I don't think it's reasonable to make a go/no go assessment on a deprecation without having done the measurement first. Adding a UseCounter is the usual process I was referring to.

To distinguish between two kinds of spammy, the false positives due to enumeration is one kind, and only applies to attributes on a few interfaces. This makes a use counter not useful to get an upper bound on the risk. But, if the actual usage of document.origin were super high, then a deprecation message would be spammy in the sense that a lot of people see it, but then we probably also shouldn't try removing it.

Also your query to httparchive seems to look for document.origin, but lots of code is minified. How common is ".origin" ?

FWIW, I think httparchive searches are mostly useful to figure out what typical usage looks like. (So yes, the percentage I named isn't very meaningful.) Trying to find minimized code increases the false positives by a lot. There are just 197 matches for "document.origin", while ".origin" has 3203720 matches it seems. (Too large response, so I used COUNT().)

Having the use counter data would be nice. I would expect it to come out at about 0.01% due to enumeration, but the web is a surprising place.

Mike, any chance to try to get a counter into M57?