Intent to Remove: webkit-prefixed IndexedDB globals

[Joshua Bell]

Primary eng (and PM) emails

jsb...@chromium.org

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/6TD2jjqAJs0/jJUNyHtbDz8J

Sent July 2014; deprecation landed in M38, which hit stable in October 2014

Summary

The IndexedDB entry point and global constructors were exposed with `webkit` prefixes as was the custom at the time, circa Chrome M11:

webkitIndexedDB (main entry point)

webkitIDBKeyRange (non-callable global constructor, but has useful static methods)

webkitIDBCursor webkitIDBDatabase webkitIDBFactory webkitIDBIndex  webkitIDBObjectStore webkitIDBRequest webkitIDBTransaction (non-callable global constructors)

We "shipped" the feature (introduced non-prefixed version) back in M24, but didn't have the deprecation process in place at the time.

Motivation

Clean up the IDLs, and get the Web using the real API.

Usage information from UseCounter

Prefixed: 0.3%
https://www.chromestatus.com/metrics/feature/timeline/popularity/3

(yes, crazy high, see below)

Unprefixed: 3%

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

(an order of magnitude higher, yay!)

0.3% is still crazy high. This is down from 0.5% before we added the deprecation warning, but relatively stable there at 0.3%, so I'm not optimistic it will drop further. The high usage appears to be due libraries using patterns like:

var indexedDB = window.indexedDB || window.webkitIndexedDB || window.mozIndexedDB;

And:

if ('webkitIndexedDB' in window) { ... }

The former could be addressed by eseidel's suggestion in the "Intent to Deprecate" thread of pulling a "document.all" trick and making window.webkitIndexedDB test as false. That wouldn't help the second. From a brief survey of github, both patterns are in use - like this example that uses both at the same time:

https://github.com/johndel/node-webkit-windows-example/blob/c1453ce45e49f252bf0c3a4ab93085d25b65f3ca/websql_develop/public/js/indexeddb.js

It seems like are options are:

* Go for it, and just be prepared to revert based on dev/beta feedback

* Wait another 6-12 months and revisit

* Make window.webkitIndexedDB test as false, and try to drive the numbers down further before removing

* Other crazy ideas?

Waiting is fine, but figured it was time to test the waters. 

Entry on chromestatus.com

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

Compatibility Risk

It never shipped as 'webkitIndexedDB' in Safari, so we're only at risk of breaking Chrome users.

[Chris Harrelson]

I think these numbers are just too high to take any action. Do we have any data on which libraries use the deprecated values? Maybe we can ask them to remove it?

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

[Jochen Eisinger]

I wonder why a line like window.indexedDB = window.indexedDB || window.webkitIndexedDB triggers the use counter for webkitIndexedDB at all - shouldn't the evaluation end when window.indexedDB is defined?

[Joshua Bell]

On Tue, Mar 10, 2015 at 11:44 AM, Jochen Eisinger <joc...@chromium.org> wrote:

I wonder why a line like window.indexedDB = window.indexedDB || window.webkitIndexedDB triggers the use counter for webkitIndexedDB at all - shouldn't the evaluation end when window.indexedDB is defined?

Sorry, coffee hadn't soaked in yet. That obviously should short-circuit, and that example is fine.

I thought I'd seen uses that had things backwards, but I'm not finding any examples now. So modulo any further data, consider that case moot. (Which is to say, testing as false wouldn't help.)

 

On Tue, Mar 10, 2015 at 7:23 PM Chris Harrelson <chri...@chromium.org> wrote:

I think these numbers are just too high to take any action. Do we have any data on which libraries use the deprecated values? Maybe we can ask them to remove it?

Nope - I'll see if I can dig anything up.

(github is full of demo files and copies of our layout tests, so it's not ideal. But we have other means...)

[Alex Russell]

Do we have insight into who the prefixed users are?

[Philip Rogers]

We have a pretty easy way to test this on ~5M public pages using public httparchive data and bigquery. See https://groups.google.com/a/chromium.org/d/msg/blink-dev/CpIy0Pzcg4E/ynntVh1VWC8J. Removing this from modernizr drops the usage on the httparchive data by about 10x.

SELECT url,body FROM [httparchive:runs.2014_08_15_requests_body] WHERE REGEXP_MATCH(body, r'webkitIndexedDB');

1105 pages

SELECT url,body FROM [httparchive:runs.2014_08_15_requests_body] WHERE REGEXP_MATCH(body, r'webkitIndexedDB') AND NOT body CONTAINS "modernizr";

117 pages

[Alex Russell]

That sounds like a doable target for our various devrel teams to tackle.

+paulkinlan

[Simon Pieters]

On Tue, 10 Mar 2015 21:35:34 +0100, 'Joshua Bell' via blink-dev
<blin...@chromium.org> wrote:

> On Tue, Mar 10, 2015 at 11:44 AM, Jochen Eisinger <joc...@chromium.org>
> wrote:
>
>> I wonder why a line like window.indexedDB = window.indexedDB ||
>> window.webkitIndexedDB triggers the use counter for webkitIndexedDB at
>> all
>> - shouldn't the evaluation end when window.indexedDB is defined?
>>
>
> Sorry, coffee hadn't soaked in yet. That obviously should short-circuit,
> and that example is fine.
>
> I thought I'd seen uses that had things backwards, but I'm not finding
> any
> examples now. So modulo any further data, consider that case moot. (Which
> is to say, testing as false wouldn't help.)

e.g.

!(!window.indexedDB&&!window.webkitIndexedDB&&!window.mozIndexedDB)

https://github.com/coolnameismy/simplerMap/blob/0815f6c6822bd05cd3cfce6047b141da34fa52f4/javascript/dev/dojox/store/db/has.js

--
Simon Pieters
Opera Software

[Elliott Sprehn]

On Wed, Mar 11, 2015 at 2:07 AM, Simon Pieters <sim...@opera.com> wrote:

On Tue, 10 Mar 2015 21:35:34 +0100, 'Joshua Bell' via blink-dev <blin...@chromium.org> wrote:

On Tue, Mar 10, 2015 at 11:44 AM, Jochen Eisinger <joc...@chromium.org>
wrote:

I wonder why a line like window.indexedDB = window.indexedDB ||
window.webkitIndexedDB triggers the use counter for webkitIndexedDB at all
- shouldn't the evaluation end when window.indexedDB is defined?

Sorry, coffee hadn't soaked in yet. That obviously should short-circuit,
and that example is fine.

I thought I'd seen uses that had things backwards, but I'm not finding any
examples now. So modulo any further data, consider that case moot. (Which
is to say, testing as false wouldn't help.)

e.g.

!(!window.indexedDB&&!window.webkitIndexedDB&&!window.mozIndexedDB)

I don't think this should be causing it since the first clause ends up false the rest of the expression short circuits and we never access the webkitIndexedDB property.

 

https://github.com/coolnameismy/simplerMap/blob/0815f6c6822bd05cd3cfce6047b141da34fa52f4/javascript/dev/dojox/store/db/has.js

- E 

[Philip Jägenstedt]

So here's another crazy idea.

While the usage of webkitIndexedDB is high, all the other prefixed aliases have usage around 0.01%:

PrefixedIDBCursorConstructor

PrefixedIDBDatabaseConstructor

PrefixedIDBFactoryConstructor

PrefixedIDBIndexConstructor

PrefixedIDBKeyRangeConstructor

PrefixedIDBObjectStoreConstructor 

PrefixedIDBRequestConstructor 

PrefixedIDBTransactionConstructor 

I think we should remove all of these now. Even if webkitIndexedDB cannot be removed this is still worthwhile IMHO. Also, if we're really lucky the change could prompt some sites to change webkitIndexedDB to indexedDB as well.

As for webkitIndexedDB, do you have the resources internally at Google to find the biggest sites using webkitIndexedDB and reach out to them? Deprecation messages don't seem to have any effect on usage, so this is what it would take.

Philip

[Joshua Bell]

On Wed, Mar 11, 2015 at 3:37 AM, Philip Jägenstedt <phi...@opera.com> wrote:

So here's another crazy idea.

While the usage of webkitIndexedDB is high, all the other prefixed aliases have usage around 0.01%:

PrefixedIDBCursorConstructor

PrefixedIDBDatabaseConstructor

PrefixedIDBFactoryConstructor

PrefixedIDBIndexConstructor

PrefixedIDBKeyRangeConstructor

PrefixedIDBObjectStoreConstructor 

PrefixedIDBRequestConstructor 

PrefixedIDBTransactionConstructor 

I think we should remove all of these now. Even if webkitIndexedDB cannot be removed this is still worthwhile IMHO. Also, if we're really lucky the change could prompt some sites to change webkitIndexedDB to indexedDB as well.

I'd considered that (and almost sent a I2R about it a few months ago!), but removing just the constructors would break one of the samples I cited from github:

if ('webkitIndexedDB' in window) {

 window.IDBTransaction = window.webkitIDBTransaction;  window.IDBKeyRange = window.webkitIDBKeyRange;

}

You could argue that the numbers are low enough that it's okay to knowingly break that. It didn't seem worth it to just do this part, but that's just me. 

(Aside: The only reason to ever reference most of the constructors directly from code is to use attributes that were removed, so those scripts are already broken. Only IDBKeyRange is actually useful.)

[Paul Irish]

Like Philip pointed out, feature detection (typically by means of Modernizr) often triggers our UseCounters even when the feature isn't being used.   We've worked around this in a few instances, however luckily IDB 

IndexedDB is in the default set of tests that shipped in the major releases of Modernizr, and Modernizr is the 2nd most common JS library out there, 

I used Philip's query on the HTTP Archive data as a start and expanded it.

SELECT
  url,
  mimeType,
  IF (body CONTAINS "indexedDB", "standard", "") AS standard,
  IF (body CONTAINS "webkitIndexedDB", "prefixed", "") AS prefixed,
FROM
  [httparchive:runs.2014_08_15_requests_body]
WHERE
  body CONTAINS "ndexedDB";

I wanted to see if there are folks that are only using the prefix and not the standard in their code.

I'm presuming that people are normally testing for all variants but sometimes end up using prefixed because they don't know better.

Starting with 3,400,000 scripts (~200GB JS & HTML),

Filtered down to 18,000 JS files that have "ndexedDB" in them. 

I then looked at the cases where only the prefixed is in the source and not the unprefixed. 

Just 28 of those.

27 of which is a JS library that has the prefixed version in myGlobalVarBlacklist array, 

The remaining 1 result is a mis-capitalization asking for window.IndexedDB.

That's it.

As Joshua pointed out earlier, JS has been probing for the prefix status for IDB for a while. 

Given that and the above results, I don't expect problems with nuking the prefixed APIs now.

On Tue, Mar 10, 2015 at 6:54 PM, Philip Rogers <p...@chromium.org> wrote:

[Alex Russell]

LGTM++

[Philip Jägenstedt]

Thanks Paul, those are very promising numbers. That both the unprefixed and prefixed attributes are used doesn't guarantee that removing the prefixed attribute is safe, but it makes it quite likely.

I see that Boris Zbarsky has removed mozIndexedDB from Gecko and that this will be in Firefox 38, to be released on May 12:
https://bugzilla.mozilla.org/show_bug.cgi?id=975699

https://developer.mozilla.org/en-US/Firefox/Releases/38/Site_Compatibility

If we remove webkitIndexedDB now, it would be gone in Chrome 43, which should be released around May 26 (12 weeks after Chrome 41).

I think we should try removing the prefixed IndexedDB attributes, but be prepared to revert

• if a common usage pattern that would break is discovered in the wild,
• if popular.com reports a problem before it reaches stable and needs time to adapt, or
• if the Firefox removal is reverted.

We could wait and see what happens with the Firefox release, but having the removals roughly in sync would allow Web developers to update and test their code once only.

Philip

[Chris Harrelson]

Some of the API owners met today to discuss, and the consensus was that we should work with the Chrome developer relations team to gather more data on which sites would be affected and how, and figure out good best practices to get out the word/gather feedback from developers. Dimitri will chat with them to get this started.

We're hoping that this exercise will not only resolve the questions about IndexedDB, but also help us come up with a more effective way to find out the impact on sites and the developer community of borderline cases like this. It would be nice to improve on this over time (I have the recent feedback relating to font loading deprecation in mind).

I suspect that what Paul Irish concluded in this thread is correct, but a little more due diligence can't hurt. :)

Chris

[Philip Jägenstedt]

That sounds reasonable, Chris. It would be positively fantastic if we
could make a habit of identifying problematic sites and reaching out
to them in advance. I presume you'll make use of Google-internal
resources, but if you figure out techniques that can be used by
everyone to answer this kind of question, please do share!

(Unfortunately I missed the meeting.)

Philip

[Edwin Reynoso]

I know Blink is going to stop using vender prefixes. But for now here's a neat idea:

All features that have the prefix, that are now available without the prefixes should do the following (Using indexedDB example):

webkitIndexedDB does not show in the console when typing it.

However if typed in the console, return the object(indexedDB) (this will be exactly like global DOM element IDs which don't show up as an autocompletion in console when typing it)

Also keep showing: "'webkitIndexedDB' is deprecated. Please use 'indexedDB' instead." every time webkitIndexedDB is used instead of the first time.

This will not break websites/libraries using webkitIndexedDB, because it's accessible just like the global DOM element IDs.

This will most likely prevent anyone new to using indexedDB and is reading of older articles that use webkitIndexedDB from using it, because they won't see it in the console as an autocomplete.