1311322 - Show item details for DOM Cache Storage entries

Status: NEW

(DevTools :: Storage Inspector, enhancement, P3)

Description

[Szmozsánszky István [:flaki]]

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.

Comment 1

[Remy Sharp]

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).

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 3

[Jarda Snajdr [:jsnajdr]]

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.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

(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.

Comment 5

[Jarda Snajdr [:jsnajdr]]

(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.

Comment 6

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

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

Comment 7

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

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.

Comment 8

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Filter on HOTFROG.

Comment 9

[Sebastian Zartner [:sebo]]

For reference, the Chrome DevTools already show some more information. They show the response type, content type, content length and the time when the request was cached in the list of entries.

Clicking an entry allows you to see the full request information plus a preview of the contents.

Sebastian