Special UI for opaque responses in Applications DevTools panel |
||||||||
Issue description
Chrome Version: (copy from chrome://version)
OS: (e.g. Win10, MacOS 10.12, etc...)
What steps will reproduce the problem?
(1) Add an opaque response to the Cache Storage API. The following is sufficient if you run it in the console of an arbitrary page served on a secure origin:
const cache = await caches.open('test-cache')
const request = new Request('https://www.google.com/images/branding/product/ico/googleg_lodp.ico', {mode: 'no-cors'});
const response = await fetch(request);
cache.put(request, response);
(2) As per https://bugs.chromium.org/p/chromium/issues/detail?id=796060#c17, these opaque responses are padded to take up several megabytes of storage quota, even though the underlying resource is much smaller (1494 bytes, in this case).
(3) Take a look at the entry in the Cache Storage viewer's UI in the Applications panel of DevTools. (See attached screenshot.)
What is the expected result?
There should be some visual indication there that the entry is an opaque response. Additionally, it would be ideal if the opaque response indicator linked to some explanatory text explaining what opaque responses are and how they make an unexpectedly large contribution to the quota usage. (I've previously written up https://stackoverflow.com/questions/39109789, and an adaption of that could be used.)
Additionally, in the "Clear storage" view of the Applications panel, when at least one opaque response contributes to the overall size calculation, it would be ideal if there were a similar visual indication and link to an explanation.
What happens instead?
Instead, developers who are not familiar with opaque responses are left with what looks like a mysterious chunk of quota consumed for no apparent reasons. This is a familiar source of confusion, leading to tweets like, e.g.:
- https://twitter.com/sergiomdgomes/status/1001128544725020673
- https://twitter.com/grigs/status/979832625140387840
,
Jun 11 2018
,
Jul 30
Issue 795582 has been merged into this issue.
,
Jul 30
,
Aug 18
pfeldman@: Would the DevTools team be interested in tackling this? We (the storage team) now have better Cache Storage ownership coverage, and should be able to implement the APIs needed to support this. Marking Available until we have feedback from DevTools.
,
Aug 20
With the API in hand, we can do that.
,
Sep 6
,
Oct 3
,
Oct 26
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ce8a01b63e902ded8046d723aa16e905909dd15e commit ce8a01b63e902ded8046d723aa16e905909dd15e Author: Harley Li <hhli@chromium.org> Date: Fri Oct 26 15:14:20 2018 Add indication of the type of response a cached resource came from If a cached resource is from an opaque response, it will by design takes up more cache storage space than its real size. The indication inside the data grid of Application > Cache Storage shows the response type so users won't be baffled about unexpectedly huge cache storage usage. Resolved the merge conflict in CL1256018. Bug: 847462 Change-Id: I885dd62cc3528d29fd4abd789e4727aca028ba59 Reviewed-on: https://chromium-review.googlesource.com/c/1259299 Reviewed-by: Erik Luo <luoe@chromium.org> Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Haihong Li (Harley) <hhli@chromium.org> Cr-Commit-Position: refs/heads/master@{#603096} [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/WebKit/LayoutTests/http/tests/devtools/cache-storage/cache-data-expected.txt [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/WebKit/LayoutTests/http/tests/devtools/cache-storage/cache-data.js [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/WebKit/LayoutTests/http/tests/devtools/cache-storage/cache-deletion-expected.txt [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/WebKit/LayoutTests/http/tests/devtools/cache-storage/cache-entry-deletion-expected.txt [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/WebKit/LayoutTests/http/tests/devtools/cache-storage/cache-live-update-cache-content-expected.txt [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/blink/renderer/core/inspector/browser_protocol.pdl [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/blink/renderer/devtools/front_end/application_test_runner/CacheStorageTestRunner.js [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/blink/renderer/devtools/front_end/resources/ServiceWorkerCacheViews.js [modify] https://crrev.com/ce8a01b63e902ded8046d723aa16e905909dd15e/third_party/blink/renderer/modules/cache_storage/inspector_cache_storage_agent.cc
,
Oct 26
Added a new column to the cache entry table to indicate the response type, and a link (developers.google.com) to an explanation of opaque responses' impact on cache space usage.
,
Oct 26
Specifically, the complete URL of that link is https://developers.google.com/web/tools/workbox/guides/storage-quota#beware_of_opaque_responses
,
Oct 26
Awesome! The guidance recommended by that link assumes developers are using the "workbox" libraries, though. jeffy@ - maybe we can document a more generic explanation/guidance somewhere, e.g. based on your https://stackoverflow.com/questions/39109789/what-limitations-apply-to-opaque-responses/39109790#39109790 ?
,
Oct 29
Yeah, fair enough. I spoke with Pete LePage and I think the best home for that info is https://developers.google.com/web/tools/chrome-devtools/progressive-web-apps#caches I will put together a new paragraph there that we could link to, and share the URL once it's live.
,
Oct 30
https://github.com/google/WebFundamentals/pull/6781 has been merged, and https://developers.google.com/web/tools/chrome-devtools/progressive-web-apps#opaque-responses is the URL that you could link to from the DevTools UI. (That merged PR should go live within the next day or so.)
,
Nov 6
Thanks. The new URL is merged into Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/1320709 The new URL is https://developers.google.com/web/tools/chrome-devtools/progressive-web-apps#opaque-responses (same as comment #14).
,
Nov 6
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cccac76e50bdf962ef6f020c1489330643443ca3 commit cccac76e50bdf962ef6f020c1489330643443ca3 Author: Harley Li <hhli@chromium.org> Date: Tue Nov 06 20:50:51 2018 [DevTools] Update link URL The original URL points to an article outside of DevTools's website. This patch updates to URL to a newly-added article section inside DevTools's website. That article section was added by: https://github.com/google/WebFundamentals/pull/6781 Bug: 847462 Change-Id: If93df903011a714c657ff673c01376c2a5ee78ec Reviewed-on: https://chromium-review.googlesource.com/c/1320709 Reviewed-by: Erik Luo <luoe@chromium.org> Commit-Queue: Haihong Li (Harley) <hhli@chromium.org> Cr-Commit-Position: refs/heads/master@{#605814} [modify] https://crrev.com/cccac76e50bdf962ef6f020c1489330643443ca3/third_party/blink/renderer/devtools/front_end/resources/ServiceWorkerCacheViews.js
,
Nov 29
Per the UX meeting, the link to the opaque response article is moved to the "Clear Storage" page, just above the pie chart, because this is where users are most likely to check first when they receive an err of storage quota exceeded.
,
Nov 29
(following up Comment 17) ... and because adding a link to every "opaque-response" entry in the cache table is not aesthetically pleasing (especially when there are multiple opaque-response entries), links inside that table is dropped and moved to the "clear storage" page.
,
Nov 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f9b30cc6c37d8794d896e9f2260096628d1bb687 commit f9b30cc6c37d8794d896e9f2260096628d1bb687 Author: Harley Li <hhli@chromium.org> Date: Thu Nov 29 23:19:30 2018 [DevTools] Move opaque response explanatory link to 'clear storage' view The original palce of that link is in service worker cache table, but it makes more sense to have that link in the 'clear cache' view, since the user is probably looking at the latter when they got an exception about cache quota exceeding, which is probably caused by caching an opaque response (UI meeting 11/07). Bug: 847462 Change-Id: I99b039fc5b9617c1d0f4493dc3accce32d0385b3 Reviewed-on: https://chromium-review.googlesource.com/c/1325083 Reviewed-by: Erik Luo <luoe@chromium.org> Commit-Queue: Haihong Li (Harley) <hhli@chromium.org> Cr-Commit-Position: refs/heads/master@{#612425} [modify] https://crrev.com/f9b30cc6c37d8794d896e9f2260096628d1bb687/third_party/blink/renderer/devtools/front_end/resources/ClearStorageView.js [modify] https://crrev.com/f9b30cc6c37d8794d896e9f2260096628d1bb687/third_party/blink/renderer/devtools/front_end/resources/ServiceWorkerCacheViews.js |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by jakearchibald@chromium.org
, May 29 2018