Intent to Remove: webkitStorageInfo

[Joshua Bell]

Primary eng (and PM) emails

jsb...@chromium.org

Link to “Intent to Deprecate” thread

Predates the Intent process, but happily logging since 2013: https://bugs.webkit.org/show_bug.cgi?id=88396

Summary

In 2011 Chrome implemented the following prefixed proposed quota API:

• window.webkitStorageInfo.queryUsageAndQuota()
  
• window.webkitStorageInfo.requestQuota()
  

Once this design got a bit more review it was folded into a Quota API spec, renaming the entry points and moving them to navigator so it could be used from workers. The old API was left in parallel with a deprecation message logged to console. The old API was never implemented by any other browser.

Motivation

We plan to ship a more modern API (navigator.storage.estimate()) soon - Firefox has it implemented behind a flag. Up until recently we had 4 web-facing quota APIs (2 prefixed, 2 experimental) - we'd like to have as clean a story as possible here before we promote usage of the new API.

Compatibility And Interoperability Risk

API has been supported since 2011 and has logged a deprecation warning since March 2013.

• Edge: Not supported
  
• Firefox: Not supported - new navigator.storage.estimate() API implemented behind a flag pending further work
  
• Safari: Not supported
  
• Web developers: No signals.

Alternative implementation suggestion for web developers

The deprecation warning suggests:

'window.webkitStorageInfo' is deprecated. Please use 'navigator.webkitTemporaryStorage' or 'navigator.webkitPersistentStorage' instead.

Which is true. Of course, that's another API that's not had adoption outside of Chrome. Another approach would be to wait until the new hotness is ready and shipping in two browsers, then proceed with deprecating both of the old prefixed APIs. Reviewing the numbers, though, ditching this one now seems plausible.

Usage information from UseCounter

The top level use counter (PrefixedStorageInfo) reports 0.6% but enumerating the global properties (common!) will tick it, so it can't be trusted to reflect actual usage. Two more histograms were added to track the actual methods. Those haven't hit stable but relative to the top level counter the 28 day aggregation for dev we can do some math:

• V8DeprecatedStorageInfo_QueryUsageAndQuota_Method: 0.003% (estimated)
  
• V8DeprecatedStorageInfo_RequestQuota_Method: 0.00006% (estimated)

The former is on the edge for our deprecation threshold. We can also wait for those metrics to hit stable.

For reference, the suggested replacement API navigator.webkitTemporaryStorage (etc) numbers are 0.5% (top level) and the actual method usage is around 0.02% (estimated - hasn't hit stable yet). We're going to be living with that one for quite some time, it seems.

OWP launch tracking bug

Just tracked as crbug.com/695586 - will file OWP if approved.

Entry on the feature dashboard

Will file if approved.

[Rick Byers]

0.003% is sufficiently non-trivial that it seems a bit of a shame to ask those users to switch to another non-standard API when a standard replacement will be available "soon".  Perhaps the navigator.webkitTemporaryStorage usage is actually a small number of sites/libraries and so is something we may be able to drive down / remove?  What's the downside of waiting until the new API ships before removing this long-deprecated one?  What's your best guess of how soon "soon" is?

An HTTP Archive analysis of the queryUsageAndQuota usage might show us that it's likely only a small number of sites / libraries, in which case my concern above probably isn't worth worrying about.  But I don't know if it's worth the effort to do that analysis vs. just waiting for navigator.storage.estimate to ship when we can have a nice coherent story around "there's finally a standard set of quota APIs - please use them!".

Rick

[Joshua Bell]

On Mon, Mar 20, 2017 at 12:35 PM, Rick Byers <rby...@chromium.org> wrote:

0.003% is sufficiently non-trivial that it seems a bit of a shame to ask those users to switch to another non-standard API when a standard replacement will be available "soon". 

Yep. On the flip side, they've been seeing deprecation warnings for 4 years w/o taking action. I'm not optimistic we'll get any motion...

 

Perhaps the navigator.webkitTemporaryStorage usage is actually a small number of sites/libraries and so is something we may be able to drive down / remove? 

Hopefully. The promise of cross-browser support may help?

 

What's the downside of waiting until the new API ships before removing this long-deprecated one? 

Nothing, really, just trying to be incremental. The code is all API implementation, as the plumbing remains the same for all the variation.

 

What's your best guess of how soon "soon" is?

Depends on Mozilla; from inspecting the bugs it looks like it's just blocked on getting [SecureContext] implemented but I'm unsure. (They actually announced navigator.storage in the 51 notes but didn't mention it was behind a flag.) So... I'm optimistic for Q2.

 

An HTTP Archive analysis of the queryUsageAndQuota usage might show us that it's likely only a small number of sites / libraries, in which case my concern above probably isn't worth worrying about.  But I don't know if it's worth the effort to do that analysis vs. just waiting for navigator.storage.estimate to ship when we can have a nice coherent story around "there's finally a standard set of quota APIs - please use them!".

Querying on webkitStorageInfo.queryUsageAndQuota it looks like all but a couple hits are from use of two libraries across sites: a DailyMotion Player JS API and Peer5 JS API. In both cases the code is no longer (so far as I can tell) in tip-of-tree in their github repos but I need to untangle the code investigate the fallback behavior, and understand why users of their CDNs aren't getting the latest code - maybe API keys do version pinning or some such.

I'll follow up on this.

[Philip Jägenstedt]

The deprecation message for this isn't great, and there would some value in getting rid of it. If we're worried about advertising for webkitTemporaryStorage and webkitPersistentStorage, the high level of deprecation message logging due to enumeration may be doing more than a removal would.

But... it would be great if people can adjust their code once and not be annoyed a second time when we ask them to move to a non-prefixed API. If it turns out that none of the usage of webkitStorageInfo found in the wild actually needs to be changed in reaction to removal then I think we should just remove it, but if it'll be a breaking change then maybe waiting a few months more is better.