Intent to Deprecate and Remove : Remove Non-standard APIs in Document.

[Yeol Park]

Primary eng emails

pea...@gmail.com

Summary

The goal is to deprecate (and eventually remove) the non-standard APIs |webkitHidden| and |webkitVisibilityState| in Document

Motivation

This method is no longer part of the spec.

Should replace it with a standard APIs.

https://www.chromestatus.com/features/5689697795833856

Compatibility Risk

The compatibility risk is low. 

|webkitHidden| and |webkitVisibilityState| APIs was removed w3c part of the spec.

[W3C] 4. Page Visibility : https://www.w3.org/TR/page-visibility/#sec-document-interface

Usage information from UseCounter

Usage is low than 4%:

https://www.chromestatus.com/metrics/feature/popularity#PrefixedPageVisibility

OWP launch tracking bug

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

Entry on the feature dashboard

https://www.chromestatus.com/features/5689697795833856

Requesting approval to remove too?

Yes

[Elliott Sprehn]

Sgtm. Btw in the future it'd be great if you could put the name of the properties in the email subject, it helps triage and review the intents. :)

[Jochen Eisinger]

Almost 4% is really high usage. How did you arrive at the conclusion that the compatibility risk is low?

[Yeol Park]

Sorry, I thought it was safe if less than 4%.

This is also only supported by Blink.

Not supported EdgeHTML, Gecko, WebKit, and IE.

Tests: https://jsbin.com/cavaxah/edit?html,output

2017년 4월 3일 월요일 오후 3시 41분 1초 UTC+9, Jochen Eisinger 님의 말:

[Dominic Cooney]

(Non-owner here.)

There's a note on the IDL that printing document in the console tickles the use counter. Is that still the case? Despite the bug in the FIXME being "Fixed" it looks like it was reverted. So 4% may not be trustworthy; but finding a measured document attribute with a much lower use counter may let you quickly discount this.

By the way, those properties are aliases through ImplementedAs=(unprefixed property) so the implementation burden or security risk of keeping them may be small. Our "Removal Guidelines" say "removals must have strong reasons" such as "security, code health, known bad practice that leads to unintuitive performance problems, ... etc."

I think there is some unresolved tension between efforts to remove all these things and our policy not to remove all these things. Maybe the API owners can shed some light.

Sincerely,

Dominic

[PhistucK]

Since no other engine supports them (not even WebKit and especially not Edge that tends to add prefixed API for compatibility reasons), it may lead to new interoperability issues (new Chrome-only-tested pages that basically support all of the browsers), so it is more than just "remove it since it is prefixed and not in the specification".

The fact that Edge did not add them does make this more safe, but some usage research should be performed (HTTPArchive, GitHub...) before discounting all of the 4% (the minimal percentage for removal used to be 0.02% or something and even that turned out not to be low enough, imagine that!).

☆PhistucK

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

[Jochen Eisinger]

We learned in the past that the usage number alone is not a reliable signal for safe removal (and even back then the cutoff was about 100x lower).

Before we can decide whether to deprecate or remove, please analyze where the usage comes from and whether it is safe to just remove the attribute, or how we can drive usage down / make it safe to remove.

[Philip Jägenstedt]

I added "interoperability" as one of the options under "Why are we removing this feature?" and think this ought to be uncontroversial, since this has been successfully used as a justification on intents like this many times. It does not mean that interoperability or any other goals are overriding, it still needs to be balanced against the cost.

[Philip Jägenstedt]

Indeed, on some interfaces use counters for attributes seem to be inflated by enumeration. This is definitely true of Event and probably Window.

The attributes with the lowest usage I could find on Document is xmlStandalone, so the "enumeration noise floor" on Document, if there is one, is under 0.01%. So, we can't blame enumeration for the high use counters in this case.

Still, since these are in Blink only, the chances should be pretty good. Yeol, do you have access to BigQuery so that you could look at the usage in httparchive? https://www.chromium.org/blink/platform-predictability/compat-tools has some advice and I'd be happy to help out if needed.

[Dominic Cooney]

Re: adding "interoperability" in your other message, great. This gives me hope that we can justify removing defaultStatus.

On Mon, Apr 3, 2017 at 4:38 PM, Philip Jägenstedt <foo...@chromium.org> wrote:

Indeed, on some interfaces use counters for attributes seem to be inflated by enumeration. This is definitely true of Event and probably Window.

The attributes with the lowest usage I could find on Document is xmlStandalone, so the "enumeration noise floor" on Document, if there is one, is under 0.01%. So, we can't blame enumeration for the high use counters in this case.

Perfect, thanks for digging that up.

[Yeol Park]

I used BigQuery to run a simple query.

  SELECT page, url

  FROM [httparchive:har.2017_03_15_chrome_requests_bodies]

  WHERE body CONTAINS 'webkitVisibilityState'

Below link is the result.

Can I know what I need to add?

- webkitVisibilityState

https://bigquery.cloud.google.com/results/chromium-visibility:bquijob_7c886501_15b3811fb99

- webkitHidden

https://bigquery.cloud.google.com/results/chromium-visibility:bquijob_10fd15_15b381d68ba

2017년 4월 3일 월요일 오후 4시 38분 32초 UTC+9, Philip Jägenstedt 님의 말:

[Philip Jägenstedt]

Note that the links to BigQuery results don't work for others, one has to save the results to a table or export the results as CSV/JSON for others to look into them.

In this case, from running queries myself on the 2017_03_15_chrome_requests_bodies table, there are 599492 hits for "webkitVisibilityState", and 353586 hits for "webkitHidden". This is much more than I usually deal with, to download those results and analyze locally would not be very practical.

However, analyzing 1% of them should be doable, and still give a good idea. You can get a random subset by doing this in BigQuery:

SELECT * FROM [httparchive:har.2017_03_15_chrome_requests_bodies]

WHERE RAND() < 0.01 AND body CONTAINS "webkitHidden";

You can save the results into a new table, and then export that to JSON. I've done that here:

https://storage.googleapis.com/blink-httparchive-export/webkitHidden.json.gz

https://storage.googleapis.com/blink-httparchive-export/webkitVisibilityState.json.gz

If you download those and gunzip them, you can then use https://github.com/foolip/unhar/blob/master/unjson to split them into individual files, 3565 webkitHidden.*.txt and 5999 webkitVisibilityState.*.txt.

Then, for the interesting part, try to categorize these files based on how webkitHidden and webkitVisibilityState are used, using grep, xargs and whatever tools you like. What you're looking for is any code that would break when these attributes are removed, and it is mostly a matter of getting all of the harmless things out of the way to find the few problematic cases.

Happy to help take a closer look if needed.

[Rick Byers]

I dug into this a bit and added the following analysis to the bug:

Looking at just the first [youtube.com], I see the expression "a.webkitVisibilityState || a.mozVisibilityState || a.visibilityState || """ in https://pubads.g.doubleclick.net/gampad/ads

This looks like a Doubleclick ads thing, so we'd expect this one script to hit a lot of pages.

Also "var vName = d.webkitVisibilityState ? 'webkitvisibilitychange' : 'visibilitychange';" is in the main script for youtube.com.  There are a handful of other hits in the main youtube script where webkitVisibilityState is checked ahead of the others.

Given that removal was successful in Safari and Edge doesn't have it, I'd personally be OK with just trying a removal and manually verifying the above 10 sites don't start failing obviously (eg. throwing unhandled exceptions) and then just keep our eyes out for reports of issues in Beta.  I'll reply to the old intent thread with this data and proposal.

If we were really worried we could try reaching out to doubleclick and other popular sites following this inverted feature-detection pattern, but personally I don't think it's worth the effort.  Given the fact no other browser has this API and the above explanation for why our metrics are useless here, I'll LGTM1 a removal without deprecation period as long as someone verifies that the top 10 sites I list in the bug do indeed appear to be unaffected by the removal.

foolip@ WDYT?

[PhistucK]

Is there a thing such as first-party-only-deprecation-warnings?

If not, perhaps there should be?

☆PhistucK

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_ByBh40irvsVt18LMvvkC-Zn9x%3DZ-B7LYHdJzAGEGRHQ%40mail.gmail.com.

[Rick Byers]

We (mainly paulmeyer@) are working on deprecation reports, and I'm already talking with some Google web infrastructure folks.  They'd almost certainly be a customer, though it would still be up to individual products to decide what (if anything) to do with the reports.

[PhistucK]

Perhaps my question was not clear - I was trying to eliminate third party (DoubleClick) deprecation warnings in the console.

More than that, the Developer Tools feature has recently added a feature - branding. It shows or can show the brand next to the request (in a column, I think). With this knowledge (or an extended version of it per script file name instead of only per domain), you can tell whether the code is, say, "vendor", "jquery" or code of a brand (DoubleClick), or application-specific code. Showing deprecation for application-specific code, even if the code just checks for the prefixed feature first, would cut down on the deprecation warnings considerably and may prompt the developer to do more about it (since it is in their own code, hopefully).

Just thinking out loud, hijacking an innocent thread. Sorry.

☆PhistucK

[Rick Byers]

Oh, but in this case that actually wouldn't help at all.  Since we expect the vast majority of usage to be a false positive (no actual harm caused by checking to see if the API exists), we would never generate a (almost always useless) deprecation warning or report.  If I'm right in my judgement, then the correct thing to do here is to just remove the API without ever bothering any developer anywhere about it ;-)

[Rick Byers]

Oh sorry, I indeed totally miss-understood (I thought "1st-party" meant "Google" in this context).   That's definitely an interesting idea.  We don't always know the source (eg. a deprecation warning hit in script that has been eval'd), but we're going to try to include what we know about the source URL in Deprecation reports.  Having the console message priority influenced by the source (eg. maybe "info" by default for cross-origin, and "warning" for same-origin) is probably worth exploring at some point.

[Philip Jägenstedt]

On Mon, Aug 7, 2017 at 9:51 PM Rick Byers <rby...@chromium.org> wrote:

I dug into this a bit and added the following analysis to the bug:

Looking at just the first [youtube.com], I see the expression "a.webkitVisibilityState || a.mozVisibilityState || a.visibilityState || """ in https://pubads.g.doubleclick.net/gampad/ads

This looks like a Doubleclick ads thing, so we'd expect this one script to hit a lot of pages.

Also "var vName = d.webkitVisibilityState ? 'webkitvisibilitychange' : 'visibilitychange';" is in the main script for youtube.com.  There are a handful of other hits in the main youtube script where webkitVisibilityState is checked ahead of the others.

Given that removal was successful in Safari and Edge doesn't have it, I'd personally be OK with just trying a removal and manually verifying the above 10 sites don't start failing obviously (eg. throwing unhandled exceptions) and then just keep our eyes out for reports of issues in Beta.  I'll reply to the old intent thread with this data and proposal.

If we were really worried we could try reaching out to doubleclick and other popular sites following this inverted feature-detection pattern, but personally I don't think it's worth the effort.  Given the fact no other browser has this API and the above explanation for why our metrics are useless here, I'll LGTM1 a removal without deprecation period as long as someone verifies that the top 10 sites I list in the bug do indeed appear to be unaffected by the removal.

foolip@ WDYT?

Oh my, I saw the bug comment at the time, but somehow archived this thread.

Given that this isn't in Safari or Edge, I think that gives us rather strong reasons to think this removal would work out. An exhaustive analysis of httparchive might reveal something interesting, but it's a big effort wouldn't shake out everything that needs to be fixed anyway.

So, I think that if the top ranked sites listed in the bug don't break, I think we should just go ahead with removal.

LGTM2 without deprecation period after such testing.

[Chris Harrelson]

LGTM3 with the same testing/research comment as Philip and Rick. Apologies that this intent got forgotten for so long.

--

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfyGeNETb_L%2B4G0eyQPECVh2OCGYWsES%3DRKRCaETF59wg%40mail.gmail.com.

[Chris Harrelson]

Actually, I take back the LGTM. There was a sudden jump to 24% in November:

https://www.chromestatus.com/metrics/feature/timeline/popularity/196

More investigation is needed to find out what is going on. It appears that a lot of google-internal code checks webkitVisibilityState.