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
*a...@chromium.org <mailto:a...@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+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@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+unsubscr...@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+unsubscr...@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.
