This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
On Mon, 26 Nov 2012, David Barrett-Kahn wrote: > > Right now this event contains no structured information, just an error > message. It'd be helpful to us to know more about what failed, so we > can know what to report to the server and take action on. It's hard to > distinguish cache update failures due to just being offline from those > which are actually causing trouble. In the second case it's also hard > to work out which resource is proving unavailable and why. > > One way to do this would be to create an AppCacheError subclass, with an > errorCode parameter, and also nullable url and httpResponseCode > properties. > > Potential error codes: > * couldn't fetch manifest (includes url and httpResponseCode) > * pre and post update manifest fetches mismatched (includes url) > * fetching a resource failed (includes url and httpResponseCode) > > Related bug: > https://code.google.com/p/chromium/issues/detail?id=161753 On Thu, 29 Nov 2012, Michael Nordman wrote: > > Sounds reasonable to me. Webkit and chromium expose information like > this via the inspector console so users/developers at that can better > diagnose problems locally. Makes sense to also expose that info to app > logic so developers could diagnose from afar.
Proposed spec changes for this: https://docs.google.com/document/d/1nlk7WgRD3d0ZcfK1xrwBFVZ3DI_e44j7QoMd5gAJC4E/edit?usp=sharing
So, it looks like Chrome implements this. Are any other browsers interesting in implementing this also? The API seems sound and straight-forward.
Happy to add this, just need another browser on board.
Blink tracking bug was http://code.google.com/p/chromium/issues/detail?id=342555
The plan is to remove appcache. It makes no sense to put more resources into the feature.