This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html Multipage: http://www.whatwg.org/C#downloading-or-updating-an-application-cache Complete: http://www.whatwg.org/c#downloading-or-updating-an-application-cache Comment: Specification should be clearer about when the downloading of the application cache starts. "These events are delayed until after the load event has fired." is a bit misleading. The chrome developer team interprets it as: Start downloading all resources from the manifest file as soon as the page loads, but just delay the events until onload event has been fired. The Firefox team is actually delaying the download of all resources from the manifest file until the onload event has been fired. Outcome in Chrome: Delay between ondownloading and oncache event is minimal(in my testcase 34ms) and in firefox the actual time it took to download all resources. Chromes approach makes these events basically useless, because they are almost at the same time and appcaching is not cancelable. With a better specification, this issue could be solved. Posted from: 90.146.74.58 by simon.schatka@compuware.com User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
This bug was cloned to create bug 18279 as part of operation convergence.
Both approaches are valid. The text you quote is a non-normative description, the exact rules are given lower down in the spec. The constraints are: - we don't want to fire the events until after the 'load' event is fired, because that way we can ensure that the events are always fired in a predictable way. - we don't want to limit when UAs can do the cache, either early or late, since there are reasons to do both. Thus we end up where we are. In practice the events are still useful. They are intended to show download progress UI, and they enable you to do so as soon as your page is loaded, starting wherever you are in the download.
(In reply to comment #2) > Both approaches are valid. The text you quote is a non-normative description, > the exact rules are given lower down in the spec. > > The constraints are: > > - we don't want to fire the events until after the 'load' event is fired, > because that way we can ensure that the events are always fired in a > predictable way. > > - we don't want to limit when UAs can do the cache, either early or late, > since there are reasons to do both. > > Thus we end up where we are. > > In practice the events are still useful. They are intended to show download > progress UI, and they enable you to do so as soon as your page is loaded, > starting wherever you are in the download. whats the point of firing progress events for events that have already finished? chrome has already done all the caching and then it is firing, that it is starting the download, the progress events and it is finished? if that is REALLY what the specification wants to allow, then why do you even bother to create those events? they are absolutely useless, just check in the onload event if the caching was successful and show a progressbar that shows 100%....
It's true that if the entire update has started and ended, there's not much point sending any of the events... Maybe we should clear the queue when the update ends, if it hasn't yet been flushed? Would that work?
An application will still want to know whether an update is available, to decide whether it wants to switch to the new version of the cache. It would be a bit strange to get an updateready event without preceding events.
Yeah, good point. How about just dropping redundant 'progress' events? So the order of events would be: If not previously cached: checking, error checking, downloading, progress, error checking, downloading, progress, cached If previously cached: checking, error, noupdate checking, noupdate checking, obsolete checking, downloading, progress, error checking, downloading, progress, updateready This is the same as now, but there'd only ever be one deferred 'progress' event.
I dunno if anyone's gonna implement this, really, given that appcache is considered obsolete, but I did the suggestion from comment 6.
Checked in as WHATWG revision r8751. Check-in comment: appcache: coalesce queued progress events. http://html5.org/tools/web-apps-tracker?from=8750&to=8751