This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7775 - are the extra events needed when status is checking or downloading
Summary: are the extra events needed when status is checking or downloading
Status: VERIFIED INVALID
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE
Depends on:
Blocks:
 
Reported: 2009-09-30 16:02 UTC by Anne
Modified: 2010-12-01 15:28 UTC (History)
5 users (show)

See Also:

Attachments

Description Anne 2009-09-30 16:02:38 UTC 
Why do the events in substep 4 and 5 need to be dispatched if the algorithm is already in progress elsewhere? Because if the algorithm is in progress the ApplicationCache update will get events on that already.
Comment 1 Anne 2009-10-01 13:53:33 UTC 
Another thing to consider here is that currently only the "cache host" that started the update process can show progress UI. Is that really desired? If the user switches tabs shouldn't it be able to see some kind of progress there too?

Maybe if people want to do that they should use Web Workers? Maybe add a note somewhere if that is the case?

Also, might it be good to explicitly tell an application author that an update is already in progress somewhere? E.g. by instead of feeding the author checking and downloading events that the author would get anyway (as far as I can tell) maybe give a specific event such as alreadyupdating.
Comment 2 Ian 'Hixie' Hickson 2009-10-18 22:08:59 UTC 
All the cache hosts get all the events. I don't understand this bug report.