[whatwg] AppCache Error events

Michael Nordman michaeln at google.com
Thu Nov 29 13:36:30 PST 2012


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.


On Thu, Nov 29, 2012 at 11:40 AM, David Barrett-Kahn <dbk at google.com> wrote:

> So are there no objections to this, should I draft a change to the spec?
>
> -Dave
>
> On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn <dbk at google.com>
> 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
> >
> > Thoughts?
> >
> > -Dave
> >
> >
>
>
> --
> -Dave
>



More information about the whatwg mailing list