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

Issue metadata

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

Sign in to add a comment

Issue 847462: Special UI for opaque responses in Applications DevTools panel

Reported by, May 29 2018 Project Member

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'test-cache')
const request = new Request('', {mode: 'no-cors'});
const response = await fetch(request);
cache.put(request, response);

(2) As per, 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, 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.:

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

Comment 1 by, May 29 2018


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

…where 'why' links to some documentation.

Comment 2 by, Jun 11 2018


Comment 3 by, Jul 30 2018

 Issue 795582  has been merged into this issue.

Comment 4 by, Jul 30 2018

 Issue 811304  has been merged into this issue.

Comment 5 by, Aug 18

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.

Comment 6 by, Aug 20

Components: -Platform>Apps>DevTools Platform>DevTools
With the API in hand, we can do that.

Comment 7 by, Sep 6

Status: Assigned (was: Available)

Comment 8 by, Oct 3

Status: Started (was: Assigned)

Comment 9 by, Oct 26

Project Member
The following revision refers to this bug:

commit ce8a01b63e902ded8046d723aa16e905909dd15e
Author: Harley Li <>
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-by: Erik Luo <>
Reviewed-by: Dmitry Gozman <>
Commit-Queue: Haihong Li (Harley) <>
Cr-Commit-Position: refs/heads/master@{#603096}

Comment 10 by, Oct 26

Status: Fixed (was: Started)
Added a new column to the cache entry table to indicate the response type, and a link ( 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

Comment 12 by, Oct 26


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 ?

Comment 13 by, Oct 29

Yeah, fair enough. I spoke with Pete LePage and I think the best home for that info is

I will put together a new paragraph there that we could link to, and share the URL once it's live.

Comment 14 by, Oct 30 has been merged, and is the URL that you could link to from the DevTools UI.

(That merged PR should go live within the next day or so.)

Comment 16 by, Nov 6

Project Member
The following revision refers to this bug:

commit cccac76e50bdf962ef6f020c1489330643443ca3
Author: Harley Li <>
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:

Bug:  847462 
Change-Id: If93df903011a714c657ff673c01376c2a5ee78ec
Reviewed-by: Erik Luo <>
Commit-Queue: Haihong Li (Harley) <>
Cr-Commit-Position: refs/heads/master@{#605814}

Comment 17 by, 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.
Screen Shot 2018-11-29 at 11.24.48.png
37.0 KB View Download

Comment 18 by, 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.

Comment 19 by, Nov 29

Project Member
The following revision refers to this bug:

commit f9b30cc6c37d8794d896e9f2260096628d1bb687
Author: Harley Li <>
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-by: Erik Luo <>
Commit-Queue: Haihong Li (Harley) <>
Cr-Commit-Position: refs/heads/master@{#612425}

Sign in to add a comment