Bug 41635 – Web Inspector: Give Application Cache Resources a Different Type & Filter in the Resources Panel

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Joseph Pecoraro]

Would be useful to differentiate and filter on Application Cache Resources.

[Michael Nordman]

It's not clear from the description which Application Cache Resources are being referred to?

- resources that are retrieved from an cache, and loaded into the page
vs
- resources that are retrieved from the network and loaded into the page

I'd vote to focus on that distinction.

But there is also...

- resources that are being fetched in the background to populate a new cache.

Seems confusing to put resource loads from the last category in the resource panel. Those resources are not being loaded into the document. There might be a better UI than co-mingling those background fetches resource loads into the active page.

[Michael Nordman]

(In reply to comment #1)
> - resources that are retrieved from an cache, and loaded into the page
> vs
> - resources that are retrieved from the network and loaded into the page
> 
> I'd vote to focus on that distinction.

One in particular to distinsquish are resource loads that result in an error by design. If a url is not represented in the appcache associated with a page. We need to provide a clear reason for failure in that case.

[Joseph Pecoraro]

To me there are 3 categories of Resources. For those who aren't familiar, the Application
Cache spec makes changes to the usual networking model. It (1) checks and potentially loads
a resource from the application cache before attempting to fetch something over the network.
(2) Otherwise it fetches the resource normally. Then there is (3) the Application Cache update
process, which fetches the resources in the background, but would be nice to visualize.
http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel

I believe these are the same 3 categories Michael Nordman described in comment 1.

I think we should handle all 3. General idea being:

  - (1) indicate in the Resources panel resources loaded from the application cache
  - (2) regular resource loads, are handled just fine already, needs no change
  - (3) somehow show resources fetched to put into the application cache

Where to show (3) is up for debate. Right now I put them in the resources panel. Its an
okay solution, at least for now. I remember in the original bug Patrick Muellr even
suggested something like a new Resources Panel. That would make sense, but I think
it is a bit heavy weight. This sounds like another vote for a "Global Inspector" for
levels higher than just per-page information.


> Seems confusing to put resource loads from the last category in the resource panel.
> Those resources are not being loaded into the document. There might be a better UI
> than co-mingling those background fetches resource loads into the active page.

I think there should be a better UI. But putting them in the Resources Panel for now
gives you a lot for free. We just have to come up with an improved UI now. That is
what this bug is for.

[Michael Nordman]

> Where to show (3) is up for debate. Right now I put them in the resources panel. Its an
> okay solution, at least for now. I remember in the original bug Patrick Muellr even
> suggested something like a new Resources Panel. That would make sense, but I think
> it is a bit heavy weight. This sounds like another vote for a "Global Inspector" for
> levels higher than just per-page information.
> 
> 
> > Seems confusing to put resource loads from the last category in the resource panel.
> > Those resources are not being loaded into the document. There might be a better UI
> > than co-mingling those background fetches resource loads into the active page.
> 
> I think there should be a better UI. But putting them in the Resources Panel for now
> gives you a lot for free. We just have to come up with an improved UI now. That is
> what this bug is for.

Our initial cut at how to represent those resource loads in the inspector is probably going to be a little different than yours. We're planning to log output to the console for update progress and errors to start with, simple logging of URLs and the response code in the event of an error. Putting info about these request in that panel doesn't come nearly as free for us as it does for you (in chrome these resource loads are performed in the main browser process).

A thought about inspecting the contents of the existing cache. We have the resource grid view that shows the list of resource in the cache. A gesture on a listing could show details, headers and body.

[Michael Nordman]

> Putting info about these request in that panel doesn't come nearly as free for us as
> it does for you (in chrome these resource loads are performed in the main browser process).

Since its really not clear having those resource in that panel is a good thing, we'll start with something simpler and figure out if there's a better answer than simple logging.

[Michael Nordman]

(In reply to comment #5)
> Since its really not clear having those resource in that panel is a good thing,
> we'll start with something simpler and figure out if there's a better answer than
> simple logging.

Fyi: Here's the logging we're doing to start with.
http://codereview.chromium.org/2910007/diff/21002/45017
We log something per event raised, the url and numDone of total is logged for progress events, and an error message is logged with error events, the error messages contain the http response code and url responsible for the error (if it was due to a bad response).