Currently the Storage inspector lists the named caches, and the items contained in them, but only shows the URL and Status of the request/response. For debugging purposes it would be useful to expose other request/response related information used in matching, such as request/response headers, optionally even expose response body.

To add to this, I was trying to debug jsconsole.com which uses a service worker, but for some reason it didn't _appear_ to have the latest content. I was able to view the assets cached, and they appeared correct (and latest) based on the URLs – specifically a new URL was included in the list. However, in my case, I wanted to check my index.html file to ensure *that* content had been updated. I was able to solve this manually in the console by opening the latest cache and matching the URL I needed, then used the `.text()` promise to inspect the body. I don't think this should be exposed by default, but it would be useful to be able to shortcut that process in a link or button in the UI (I was coming from Chrome devtools, but I'd expect/hope to see the same debugging functionality in Firefox too).

Jarda, what do you think? Seems like its mostly a UX design issue since all the data should be exposed from API.

Definitely a very desirable feature. Getting the data on the backend is easy - it will use the standard modern API exposed to web pages, very little internal Firefox knowledge is needed. The UI: Displaying the cached Request & Response is not very different from what's displayed in Netmonitor, is it? We're now working on the netmonitor.html project, rewriting the tool to React/Redux, and storage.html project will also happen sooner or later. We can the reuse the same widget for both tools.

(In reply to Jarda Snajdr [:jsnajdr] from comment #3) > The UI: Displaying the cached Request & Response is not very different from > what's displayed in Netmonitor, is it? We're now working on the > netmonitor.html project, rewriting the tool to React/Redux, and storage.html > project will also happen sooner or later. We can the reuse the same widget > for both tools. I would imagine the network monitor deals with nsIChannel objects, but Cache API returns Response objects. So it seems like the API might be a bit different.

(In reply to Ben Kelly [:bkelly] from comment #4) > I would imagine the network monitor deals with nsIChannel objects, but Cache > API returns Response objects. So it seems like the API might be a bit > different. There would be one common data structure in the frontend, used as a model to render the view, and multiple ways how to populate it at the backend - either from nsIChannels, or from the CacheStorage API.

I really like the idea of exposing `.text()`

Having looked into this I think there is a lot we can do here. We can display some security info, mime types, filename, actual filetype, image preview, JSON preview, Code / text preview. To get some of this information we need the fileMagic library ideally ported to JS but because that conversion will take time I am doing that as a side project in my own time... when that is done I plan on adding a bunch of features to this storage type.

Filter on HOTFROG.