Intent to Remove: indexedDB.webkitGetDatabaseNames()

[Joshua Bell]

Primary eng (and PM) emails

jsb...@chromium.org

Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/topic/blink-dev/2fUr-3wFPKI/discussion

We deprecated in M58, planning to remove in M60, which is coming up...

Summary

Remove the non-standard webkitGetDatabaseNames() method on IDBFactory

Motivation

We added this feature when Indexed DB was relatively new in Chrome and prefixing was all the rage. The API asynchronously returns a list of existing database names in an origin, which seemed sensible enough. The design is flawed, in that the results may be obsolete as soon as they are returned, so it can really only be used for logging, not serious application logic. The github issue https://github.com/w3c/IndexedDB/issues/31 tracks/links to previous discussion on alternatives, which would require a different approach. While there's been on-and-off interest by developers, given the lack of cross-browser progress here the problem has been worked around by library authors.

Interoperability and Compatibility Risk

Edge: Not supported

Firefox: Not supported Safari: Not supported Web developers: Requested, but only used in a handful of libraries due to lack of cross-browser adoption. Comes up on StackOverflow every so often. Tracked as a spec feature request (with links to past discussions).

Alternative implementation suggestion for web developers

Libraries like Dexie.js use a global table (another database) tracking the names of databases.

Usage information from UseCounter

Use counter: https://www.chromestatus.com/metrics/feature/timeline/popularity/1273

Note that the data is noisy and spiky - as noted in the I2I it looks like an analytics provider started using it, although this doesn't show up in HTTPArchive.

From internal data, usage is steadily dropping from 0.00004% when the deprecation warning stable to 0.00002% today.

I made sure the three libraries using it that represented nearly all HTTPArchive hits were contacted (although later than I'd planned - ooops!)

• Dexie.js: https://github.com/dfahlander/Dexie.js/issues/532
  
• AlaSQL: https://github.com/agershun/alasql/issues/877
• MegaNZ: https://github.com/meganz/webclient/issues/16

In all cases, the libraries fall back if the method is not present.

OWP launch tracking bug

Still just a regular bug: https://bugs.chromium.org/p/chromium/issues/detail?id=696010

(will file a launch tracking bug once we say "go")

Entry on the feature dashboard

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

[Chris Harrelson]

LGTM still. No further LGTMs needed, as the previous intent already approved removing in M60, and the supporting data has not changed. Thanks for the heads up though!

--
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/CAD649j4kzWuiL9fMMWyRuM_Vbk%2B7KL702ea-OLOrD%2BT-%3DEePiA%40mail.gmail.com.

[PhistucK]

You seem to have replied to the wrong thread. Reply again to this thread -

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Udxmfvq4Wf8

☆PhistucK

On Thu, May 18, 2017 at 8:33 PM, <jesse....@gmail.com> wrote:

Removing the CSS property zoom all together would be the only way to prevent the "user-hostile" property zoom, where one could still replicate zoom: reset; through JavaScript having it repeatedly setting the zoom. I personally do not wish to take out the Zoom property or take out the reset value because people like myself use it to prevent the user from causing issues with web applications that an end user could easily on accident zoom in/out without knowing how to get back to the default zoom level.

--
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/0b498cef-d21d-47b8-b561-b3f57c79efbf%40chromium.org.

[Joe Medley]

Joshua,

Is there are general tracking bug somewhere for deprecated IDB features?

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

On Wed, May 17, 2017 at 4:06 PM, Joshua Bell <jsb...@chromium.org> wrote:

--

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/CAD649j4kzWuiL9fMMWyRuM_Vbk%2B7KL702ea-OLOrD%2BT-%3DEePiA%40mail.gmail.com.

[Joshua Bell]

On Fri, May 19, 2017 at 9:04 AM, Joe Medley <jme...@google.com> wrote:

Joshua,

Is there are general tracking bug somewhere for deprecated IDB features?

No... there have really only been three classes of removals for IDB impacting stable: (1) when the spec updated circa 2011 (constants to enums, removed setVersion, etc) and it took Chrome a couple years to catch up. (2) webkit-prefixed aliases for the entry point/types, (3) this old proposed feature that never made it.

I can dig up bugs for each of those if it'd be useful - ping me offline?

[PhistucK]

I think Joe wants to warn about future possible deprecations and removals, rather than already removed features.

☆PhistucK

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

[Joshua Bell]

Ah - in that case, under the umbrella "Standardize or remove non-standard parts of Blink's IDL" (https://crbug.com/674593) the only remaining IDB one in stable is:

"Standardize or remove IDBVersionChangeEvent's dataLoss (IDBDataLossAmount) and dataLossMessage (DOMString)" (https://crbug.com/711586) 

That's the only "at risk" IDB bit.

Thanks for clarifying!

[Joe Medley]

Both, actually. I need to know about upcoming stuff so I can put it in a deps/rems article. I'm also interested in changes past in case (1) I missed it the first time around and (2) so I can make sure MDN is updated.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

On Fri, May 19, 2017 at 9:49 AM, PhistucK <phis...@gmail.com> wrote: