[Webkit-unassigned] [Bug 24529] Add support in Web Inspector for examining/changing data for HTML5 offline-Web-applications (application cache)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Apr 14 13:08:10 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=24529





--- Comment #9 from Michael Nordman <michaeln at google.com>  2010-04-14 13:08:08 PST ---
(In reply to comment #8)
> (In reply to comment #7)
> > Adding an error message is a good idea.
> 
> Except it should probably be a code, and not a message, and thus the spec
> should probably be updated.

A piece of gears history, webapp developers had a hard time with diagnosing
things going wrong in the gears.LocalServer module (the moral equivalent to 
html5.AppCache). It wasn't enough to express "some URL failed to download"
in an error code. Developers needed to know which URL was causing the
manifest update to fail. In Gears we baked the URL into an error message and
actually persisted that error messsage and made it available as an attribute
on the (equivalent of the) ApplicationCache scriptable object. Something like
the .lastErrorMessage attribute.

> > The spec does call for some additional info available in the progress events
> > thru these attribute values. These aren't implemented yet in webcore (or
> > chrome).
> > - lengthComputable, should be true
> > - total, the number of URLs to process
> > - loaded, the number of URLs that have been processed (downloaded or skipped)
> 
> Ah!  I see those now - but I had to search the spec to find them :-)   BTW, the
> spec is available at the URL field value in this bug.  Why aren't such things
> in the IDL?  Does the IDL not have a mechanism to describe these, or is the IDL
> in the spec not matching up to the wording of the spec (I'm an IDL n00b) and so
> the IDL in the spec needs to be updated.

The structure of the ProgressEvent is actually defined in a separate spec
http://dev.w3.org/2006/webapi/progress/Progress.html

> In any case, we need to open up another bug to get those properties added. 
> I'll do this if no one else has (quick search didn't find any hits)

I haven't opened a webkit bug for this, but there is a chrome bug for this.
http://code.google.com/p/chromium/issues/detail?id=39370

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list