New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 847462 link

Starred by 10 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 26
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature



Sign in to add a comment

Special UI for opaque responses in Applications DevTools panel

Project Member Reported by jeffy@chromium.org, May 29 2018

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
 
Screen Shot 2018-05-29 at 10.12.39 AM.png
88.7 KB View Download
Screen Shot 2018-05-29 at 10.12.51 AM.png
232 KB View Download
+1.

Maybe: 10mb cache storage (5mb of which is in opaque responses - why?)

…where 'why' links to some documentation.
Cc: tsteiner@google.com
Cc: bsittler@chromium.org vamshi.k...@techmahindra.com pwnall@chromium.org pfeldman@chromium.org
 Issue 795582  has been merged into this issue.
Cc: jsb...@chromium.org
 Issue 811304  has been merged into this issue.
Status: Available (was: Untriaged)
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.
Components: -Platform>Apps>DevTools Platform>DevTools
With the API in hand, we can do that.
Cc: l...@chromium.org
Owner: hhli@chromium.org
Status: Assigned (was: Available)
Status: Started (was: Assigned)
Project Member

Comment 9 by bugdroid1@chromium.org, 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

Status: Fixed (was: Started)
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.
Screen Shot 2018-10-26 at 08.33.44.png
58.6 KB View Download
Screen Shot 2018-10-26 at 08.34.31.png
69.3 KB View Download
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 ?
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.
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.)
Project Member

Comment 16 by bugdroid1@chromium.org, 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

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.
Screen Shot 2018-11-29 at 11.24.48.png
37.0 KB View Download
(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.
Project Member

Comment 19 by bugdroid1@chromium.org, 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