Primary eng (and PM) emails
Link to “Intent to Deprecate” thread
Sent July 2014; deprecation landed in M38, which hit stable in October 2014
Compatibility - since other browsers support the API unprefixed this can lead to interop problems if code relies on the prefixes, or uses it for feature detection. As a side benefit, removal cleans up our code and removes clutter in test output.
Believed to be none. The unprefixed API has been around in Chrome since M24 and is shipping in all major browsers unprefixed (http://caniuse.com/#feat=indexeddb)
Repeating some analysis by Paul Irish from last year, HTTPArchive searches turn up no pages that are obviously using the prefixed APIs that don't also use the non-prefixed API, indicating patterns such as var indexedDB = window.webkitIndexedDB || window.mozIndexedDB || window.indexedDB; The prefixed version appears on its own a few times as strings in older libraries that filter properties to ignore when doing things with the window global. Similar results for IDBXxxx vs. webkitIDBXxxx, with one exception noted below.
Usage information from UseCounter
UnprefixedIndexedDB: usage is at around 2.7% for reference
PrefixedIndexedDB: 0.15% and holding steady since January; half of what it was a year ago.
PrefixedIDBCursorConstructor: 0.015% *
PrefixedIDBFactoryContructor: 0.015% *
One caveat: PrefixedIDBCursorConstructor and PrefixedIDBFactoryContructor have recent spikes starting late September up to 0.15% (yes, 10x); from HTTPArchive this appears to be due entirely to https://cdn.adsafeprotected.com/sca.js which is used (indirectly) by many sites via ad networks and probes the existence of only webkitIDBCursor and webkitIDBFactory - it appears to be used only as part of computing a browser capability rating. (See "Motivation", above.) None of the many sites that turned up in HTTPArchive which I tested currently load this script, so it may have been retired.
OWP launch tracking bug
Will file if approved.
Entry on the feature dashboard
Will file if approved.
Note that for extra safety we'd want to do this just after a branch (e.g. after the 56 branch point). It would make sense to update the currently generic deprecation messages as well to include the target removal version/date - either slip that in before the branch or merge it in after.
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 email@example.com.