Open Bug 1311322 Opened 6 years ago Updated 2 months ago

Show item details for DOM Cache Storage entries

Categories

(DevTools :: Storage Inspector, enhancement, P3)

enhancement

Tracking

(Not tracked)

People

(Reporter: flaki, Unassigned)

References

(Blocks 2 open bugs, )

Details

(Keywords: dev-doc-needed, parity-chrome, Whiteboard: [todo-mr][t3])

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).
Summary: Show item details in DOM Cache Storage → Show item details for DOM Cache Storage entries
Jarda, what do you think?  Seems like its mostly a UX design issue since all the data should be exposed from API.
Depends on: dt-service-worker
Flags: needinfo?(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.
Flags: needinfo?(jsnajdr)
(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()`
Whiteboard: [todo-mr]
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.
Whiteboard: [todo-mr] → [todo-mr][t3]
Product: Firefox → DevTools

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

Keywords: parity-chrome
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.