Add UsageDetails dictionary

[jarryd999]

This change adds a new dictionary to the result of StorageManager.estimate() that breaks down usage by storage system.

I've opened a related TAG review here: w3ctag/design-reviews#365

---

Preview | Diff

[domenic]

This overall architecture makes sense to me now (although @annevk should check, as the editor). What remains are editorial issues.

[jarryd999]

@domenic Comments have been addressed, PTAL. If you have no further comments, then thank you for the review!

[domenic]

LGTM, but still needs editor approval. (And web platform tests!)

[inexorabletash]

@jarryd999 added "tentative" tests already in https://github.com/web-platform-tests/wpt/tree/master/storage (estimate-usage-details...)

[annevk]

Thanks for writing this up and thanks for your patience!

At a high-level I'm wondering about these things:

1. Are other implementers on board with exposing this?
2. Are there bugs filed against those implementations?
3. Is there a PR to make the tests stop being tentative that we can land together with this assuming all is in order? (There's a couple minor things I wonder about with the tests we can maybe tackle there, e.g., I don't see a need to do || 0 for the new fields as they should always be defined in a compliant implementation.)

I also left a couple remarks inline.

[annevk]

This one can contain opaque responses right? Given that this is a new place where we expose that information, I think we should also detail how to address the issue. Same for caches below.

[jarryd999]

I intentionally pulled the security part out into a separate PR in which I address the opaque response + padding issues. If you believe they should be merged in the PR, I can consolidate the two. Thoughts?

[annevk]

The other PR did not have the necessary wording either, right? But yeah, I think they should be included here and should probably be noted closer to where we define these features. Not in a separate section somewhere. The separate section seems like a fine place to highlight some of the trickier areas, but in general we should note security requirements right alongside general implementation requirements.

[jarryd999]

I've taken a stab at adding a recommendation for padding. Please take a look when you get a chance, thanks!

[annevk]

This should be something like {{Caches}} or {{Cache}}, no? Referring to the getter seems a little weird.

[jarryd999]

My understanding was that it should link here: https://w3c.github.io/ServiceWorker/#cache-objects

When I used {{Cache}}, it linked here https://w3c.github.io/ServiceWorker/#cache.

When I used {{Caches}} or {{cache-objects}}, it did not create a link (it was just grey text).

Please advise.

[annevk]

I guess you want {{CacheStorage}}? @jakearchibald thoughts?

[inexorabletash]

The other definitions don't link to an interface... I'd expect a link to the top level concept rather than an interface, e.g. https://w3c.github.io/ServiceWorker/#cache-objects

I don't think there's an export from SW there. So yeah, @jakearchibald ?

[inexorabletash]

Note that we could do this by adding a <pre class=anchors>...</pre> section w/o an explicit export from SW, but let's figure out what we want here. FWIW over in https://wicg.github.io/web-locks/ I wanted to do something similar and ended up with "Caches [Service-Workers])" where "Caches" was not a link and latter bit was just a biblio link, assuming readers would figure it out.

[jarryd999]

Thanks for the review!

1. Are other implementers on board with exposing this?

There has been no public support, but also no opposition.

2. Are there bugs filed against those implementations?

Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1565716
Safari: https://bugs.webkit.org/show_bug.cgi?id=199762

3. Is there a PR to make the tests stop being tentative that we can land together with this assuming all is in order? (There's a couple minor things I wonder about with the tests we can maybe tackle there, e.g., I don't see a need to do || 0 for the new fields as they should always be defined in a compliant implementation.)

https://chromium-review.googlesource.com/c/chromium/src/+/1700564

[annevk]

@jarryd999 could you check if #86 would make it significantly easier to define this? It seems to me we'd only have to define storage usage of a bucket's area and this would all fall out automatically.

Is there a reason for excluding localStorage?

[jarryd999]

@annevk I'm not seeing how #86 makes this significantly easier to define. I think we are partially aligned: I've always imagined usageDetails to show a breakdown of usage per-bucket. However, I am confused why the addition of buckets would mean this "would all fall out automatically", as I think the only change would be to the scope of usageDetails. Could you help me understand?

localStorage was excluded because it is currently not quota-managed. My thoughts on this are that all storage should be quota-managed, or that at the least, quota should be aware of all storage, and thus it should be displayed in usageDetails. However, I'm not too familiar with the story around localStorage.

[annevk]

Various APIs fit into a single bucket, each assigned to an area. For this we'd only need to define the primitive of obtaining the size of an area and then with some loops we can fill in all the details.