Intent to Remove: window.webkitStorageInfo

[Ayu Ishii]

Contact emails
ay...@chromium.org 

Specification
https://storage.spec.whatwg.org/

Summary
We propose to remove the following prefixed quota API, window.webkitStorageInfo in M106.

• window.webkitStorageInfo.queryUsageAndQuota()

• window.webkitStorageInfo.requestQuota()

The deprecation thread predates the Intent process, but has been marked as deprecated since 2013 (https://bugs.webkit.org/show_bug.cgi?id=88396).

Blink component
Blink>Storage>Quota

Motivation
Chrome proposed and implemented the prefixed quota API in 2011, which was immediately succeeded by the Quota API which has since been deprecated as well. The legacy storage quota API was never implemented by any other browser, and has been showing a deprecation warning since 2013. Rather than investing more support on these legacy APIs, we propose to remove it entirely.

Search tags
legacy, quota, storage

TAG review
N/A

Risks
We previously made an attempt to remove window.webkitStorageInfo in 2017 (I2D). Since then, the modern quota API navigator.storage.estimate() shows increased adoption while window.webkitStorageInfo usage has decreased.

The top level use counter (PrefixedStorageInfo) still reports 0.6% of page loads, but we think this can’t be trusted since enumeration of global properties is common and will tick the counter. The actual  usage of the methods on webkitStorageInfo: is significantly lower:

• window.webkitStorageInfo.queryUsageAndQuota() - 0.000632%

• window.webkitStorageInfo.requestQuota() - 0.000172%

As a replacement for window.webkitStorageInfo.queryUsageAndQuota(), we recommend using the now standardized navigator.storage.estimate(). This has been added to Chrome since M61, and adopted by Firefox since M57. 

window.webkitStorageinfo.requestQuota() will not have a recommended replacement. Although navigator.webkitXXXStorage.requestQuota() will still exist, this has never been standardized or adopted by other browsers. Its current usage is at 0.01% and will need to do some work before full removal, but we are motivated to remove them. Explicitly requesting quota is only used in conjunction with the deprecated and Chrome-only webkitRequestFileSystem() API, which we also hope to remove when feasible.

This removal is part of a larger effort to remove deprecated storage APIs from the codebase. For feedback on other API deprecations, please use this doc for commenting.

Interoperability and Compatibility

Gecko: Never implemented

WebKit: Never  implemented

Web developers: No signals

Debuggability
Shows a deprecation warning in the console when used (since 2013).

Is this feature fully tested by web-platform-tests?
no

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=695586

Estimated milestones
Removal proposed for M106

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5659629104136192

[Daniel Bratell]

The low usage counters indicate that this is something that could relatively safely be removed, though I wonder if you have taken a look at any of the sites listed with the usage counter?

/Daniel

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1534fcf9-585e-437c-a014-9eb5ba82ed2en%40chromium.org.

[Ayu Ishii]

Hi Daniel,

Looking through websites I was able to observe from HTTPArchive, here are some usage patterns I was able to see.

Most were used via js libraries listed below. Most usages check if window.webkitStorageInfo exists before usage.
Thanks!

window.webkitStorageInfo.requestQuota (163 total urls)

• 90 urls - browserfs - not actively worked on

• 38 urls - dojo - old version / checks if exists first

• 12 urls - mymonero js - old version / checks if exists first

• 6 urls - sencha ext js - old version?

• 16 urls remain (8 checks if exists first)

window.webkitStorageInfo.queryUsageAndQuota (285 total urls)

• 237 urls - twitter share js (example) - checks if exists first

• 38 urls - dojo - checks if exists first

• 2 urls - meteor.js - checks if exists first

• 8 urls remain (6 checks if exists first)

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

[Mike Taylor]

Hi Ayu,

Thanks for digging into usage! I'm encouraged by the fact that browserfs (even if not actively maintained) does do internal feature detection, and supports multiple storage API backends in case a site does run into trouble.

LGTM1 to remove window.webkitStorageInfo

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1c4da014-02c2-4bf1-9085-6efcb4857401n%40chromium.org.

[Yoav Weiss]

LGTM2 to remove!

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1534fcf9-585e-437c-a014-9eb5ba82ed2en%40chromium.org.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1c4da014-02c2-4bf1-9085-6efcb4857401n%40chromium.org.

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0ab3481-0469-3d74-1d03-11a70d6da3be%40chromium.org.

[Manuel Rego Casasnovas]

LGTM3

On 03/08/2022 10:12, Yoav Weiss wrote:
> LGTM2 to remove!
>
> On Wed, Aug 3, 2022 at 3:41 AM Mike Taylor <mike...@chromium.org
> <mailto:mike...@chromium.org>> wrote:
>
> Hi Ayu,
>
> Thanks for digging into usage! I'm encouraged by the fact that
> browserfs (even if not actively maintained) does do internal feature
> detection

> <https://github.com/jvilk/BrowserFS/blob/master/src/backend/HTML5FS.ts#L181-L183>,

> and supports multiple storage API backends

> <https://github.com/jvilk/BrowserFS#backends> in case a site does

> run into trouble.
>
> LGTM1 to remove window.webkitStorageInfo
>
>
> On 8/2/22 6:20 PM, Ayu Ishii wrote:
>> Hi Daniel,
>>
>> Looking through websites I was able to observe from HTTPArchive,
>> here are some usage patterns I was able to see.
>> Most were used via js libraries listed below. Most usages check if
>> window.webkitStorageInfo exists before usage.
>> Thanks!
>>
>> window.webkitStorageInfo.requestQuota (163 total urls)
>>

>> *
>>
>> 90 urls - browserfs <https://www.npmjs.com/package/browserfs>

>> - not actively worked on
>>

>> *
>>
>> 38 urls - dojo <https://dojotoolkit.org/documentation/> - old

>> version / checks if exists first
>>

>> *

>>
>> 12 urls - mymonero js

>> <https://github.com/mymonero/mymonero-core-js> - old version /
>> checks if exists first
>>
>> *

>>
>> 6 urls - sencha ext js

>> <https://www.sencha.com/products/extjs/> - old version?
>>
>> *

>>
>> 16 urls remain (8 checks if exists first)
>>
>>
>> window.webkitStorageInfo.queryUsageAndQuota (285 total urls)
>>

>> *

>>
>> 237 urls - twitter share js (example

>> <https://abs.twimg.com/responsive-web/client-web/main.c30b8418.js>)

>> - checks if exists first
>>

>> *
>>
>> 38 urls - dojo <http://dojo> - checks if exists first
>>
>> *
>>
>> 2 urls - meteor.js <https://www.meteor.com/> - checks if
>> exists first
>>
>> *

>>
>> 8 urls remain (6 checks if exists first)
>>
>>
>> On Wednesday, July 27, 2022 at 8:19:45 AM UTC-7 Daniel Bratell wrote:
>>
>> The low usage counters indicate that this is something that
>> could relatively safely be removed, though I wonder if you
>> have taken a look at any of the sites listed with the usage
>> counter?
>>
>> /Daniel
>>
>> On 2022-07-26 23:26, Ayu Ishii wrote:

>>> *Contact emails
>>> *ay...@chromium.org <mailto:ay...@chromium.org> 
>>>
>>> *Specification
>>> *https://storage.spec.whatwg.org/
>>> <https://storage.spec.whatwg.org/>
>>>
>>> *Summary
>>> *We propose to remove the following prefixed quota API,
>>> window.webkitStorageInfo in M106.
>>>
>>> *
>>>
>>> window.webkitStorageInfo.queryUsageAndQuota()
>>>
>>> *

>>>
>>> window.webkitStorageInfo.requestQuota()
>>>
>>> The deprecation thread predates the Intent process, but has
>>> been marked as deprecated since 2013
>>> (https://bugs.webkit.org/show_bug.cgi?id=88396

>>> <https://bugs.webkit.org/show_bug.cgi?id=88396>).
>>>
>>> *Blink component
>>> *Blink>Storage>Quota
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorage%3EQuota>
>>>
>>> *Motivation
>>> *Chrome proposed and implemented
>>> <https://wiki.whatwg.org/wiki/Quota> the prefixed quota API

>>> in 2011, which was immediately succeeded by the Quota API

>>> <https://www.w3.org/TR/2012/WD-quota-api-20120703/> which has

>>> since been deprecated as well. The legacy storage quota API
>>> was never implemented by any other browser, and has been
>>> showing a deprecation warning since 2013. Rather than
>>> investing more support on these legacy APIs, we propose to
>>> remove it entirely.
>>>

>>> *Search tags
>>> *legacy <https://chromestatus.com/features#tags:legacy>,
>>> quota <https://chromestatus.com/features#tags:quota>, storage
>>> <https://chromestatus.com/features#tags:storage>
>>>
>>> *TAG review
>>> *N/A
>>>
>>> *Risks
>>> *We previously made an attempt to remove
>>> window.webkitStorageInfo in 2017 (I2D
>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/YcCr-aKGb5k/m/LuyNun5iCAAJ>).

>>> Since then, the modern quota API navigator.storage.estimate()
>>> shows increased adoption while window.webkitStorageInfo usage
>>> has decreased.
>>>
>>> The top level use counter (PrefixedStorageInfo

>>> <https://chromestatus.com/metrics/feature/timeline/popularity/57>)

>>> still reports 0.6% of page loads, but we think this can’t be
>>> trusted since enumeration of global properties is common and
>>> will tick the counter. The actual  usage of the methods on
>>> webkitStorageInfo: is significantly lower:
>>>

>>> *
>>>
>>> window.webkitStorageInfo.queryUsageAndQuota()
>>> <https://chromestatus.com/metrics/feature/timeline/popularity/1808>
>>> - 0.000632%
>>>
>>> *
>>>
>>> window.webkitStorageInfo.requestQuota()
>>> <https://chromestatus.com/metrics/feature/timeline/popularity/1809>

>>> - 0.000172%
>>>
>>> As a replacement for
>>> window.webkitStorageInfo.queryUsageAndQuota(), we recommend
>>> using the now standardized navigator.storage.estimate()

>>> <https://storage.spec.whatwg.org/#ref-for-dom-storagemanager-estimate>.

>>> This has been added to Chrome since M61, and adopted by
>>> Firefox since M57. 
>>>
>>> window.webkitStorageinfo.requestQuota() will not have a
>>> recommended replacement. Although
>>> navigator.webkitXXXStorage.requestQuota()

>>> <https://www.w3.org/TR/2012/WD-quota-api-20120703/#widl-StorageQuota-requestQuota-void-unsigned-long-long-newQuotaInBytes-StorageQuotaCallback-successCallback-StorageErrorCallback-errorCallback>

>>> will still exist, this has never been standardized or adopted
>>> by other browsers. Its current usage is at 0.01%

>>> <https://chromestatus.com/metrics/feature/timeline/popularity/1811>

>>> and will need to do some work before full removal, but we are
>>> motivated to remove them. Explicitly requesting quota is only
>>> used in conjunction with the deprecated and Chrome-only
>>> webkitRequestFileSystem() API, which we also hope to remove
>>> when feasible.
>>>
>>> This removal is part of a larger effort to remove deprecated
>>> storage APIs from the codebase

>>> <https://docs.google.com/document/d/1HNwvk4jxV4uFCIRXzhU6sW_PlnPY33iuGQ8I7n9v3OM/edit?usp=sharing>.

>>> For feedback on other API deprecations, please use this doc
>>> for commenting.
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Gecko: Never implemented
>>>
>>> WebKit: Never  implemented
>>>
>>> Web developers: No signals
>>>
>>>

>>> *Debuggability
>>> *Shows a deprecation warning in the console when used (since

>>> 2013).
>>>
>>> Is this feature fully tested by web-platform-tests

>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>*?
>>> *no
>>>
>>> *Tracking bug
>>> *https://bugs.chromium.org/p/chromium/issues/detail?id=695586
>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=695586>
>>>
>>> *Estimated milestones
>>> *Removal proposed for M106
>>>
>>> *Link to entry on the Chrome Platform Status
>>> *https://chromestatus.com/feature/5659629104136192

>>> <https://chromestatus.com/feature/5659629104136192>
>>>
>>> --
>>> 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+...@chromium.org

>>> <mailto:blink-dev+...@chromium.org>.

>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1534fcf9-585e-437c-a014-9eb5ba82ed2en%40chromium.org

>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1534fcf9-585e-437c-a014-9eb5ba82ed2en%40chromium.org?utm_medium=email&utm_source=footer>.

>>
>> --
>> 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+...@chromium.org

>> <mailto:blink-dev+...@chromium.org>.

>> To view this discussion on the web visit

>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1c4da014-02c2-4bf1-9085-6efcb4857401n%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1c4da014-02c2-4bf1-9085-6efcb4857401n%40chromium.org?utm_medium=email&utm_source=footer>.

>
>
> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0ab3481-0469-3d74-1d03-11a70d6da3be%40chromium.org
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d0ab3481-0469-3d74-1d03-11a70d6da3be%40chromium.org?utm_medium=email&utm_source=footer>.

>
> --
> 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+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXeCNmBRSM4UP9c790XzbBk0k5Z6XQuJ0rR7zMRFaG3dQ%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXeCNmBRSM4UP9c790XzbBk0k5Z6XQuJ0rR7zMRFaG3dQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[jmedley via Chromestatus]

My notes say this is shipping in 106. Regardless, please enter the shipping milestone in the correct fields. (Click Edit all fields, the scroll to the bottom.) Thanks, Joe

[Ayu Ishii]

Hi everyone,

Updating the thread to inform that we have decided to extend the target milestone until we've properly informed our partners. Will update the thread again when we have a new target.

Thanks,
Ayu

[Mike Taylor]

Thanks for the heads up Ayu.

--

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/13fd6dd9-aceb-4fd8-af25-4603d523c478n%40chromium.org.

[Ben Morss]

Thanks for doing this, Ayu. Once our mechanisms are in place for informing partners more thoroughly, I think these deprecations will be simpler!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2fa2d9e-1da7-edec-5fe6-9a28fede890e%40chromium.org.

[jmedley via Chromestatus]

Is this shipping in 106?

[Joshua Bell]

NOT shipping in 106.

Since this is not a security-motivated removal (there are other APIs that provide the same data), despite the usage numbers being extremely low we are holding until we've made our best effort to reach out to partners using Chrome in scenarios where we may not have usage metrics, just to avoid surprises. 

ayui@ will update the thread when we have a new target milestone.

On Tue, Aug 23, 2022 at 11:20 AM jmedley via Chromestatus <admin+...@cr-status.appspotmail.com> wrote:

Is this shipping in 106?

--
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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/000000000000faac1205e6ec9e4f%40google.com.

[Ayu Ishii]

New target milestone for removal is M110, with enterprise policy available for 2 milestones (M110-111).

Thanks,

Ayu

On Tuesday, August 23, 2022 at 1:31:18 PM UTC-7 Joshua Bell wrote:

NOT shipping in 106.

Since this is not a security-motivated removal (there are other APIs that provide the same data), despite the usage numbers being extremely low we are holding until we've made our best effort to reach out to partners using Chrome in scenarios where we may not have usage metrics, just to avoid surprises. 

ayui@ will update the thread when we have a new target milestone.

On Tue, Aug 23, 2022 at 11:20 AM jmedley via Chromestatus <admin+jmedley@cr-status.appspotmail.com> wrote:

Is this shipping in 106?

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

[Ayu]

New target milestone for removal is M110, with enterprise policy available for 2 milestones (M110-111).

Thanks,
Ayu

On Tuesday, August 23, 2022 at 1:31:18 PM UTC-7 Joshua Bell wrote: