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 7784 - "cache failure steps" feedback
Summary: "cache failure steps" feedback
Status: RESOLVED FIXED
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-10-01 13:43 UTC by Anne
Modified: 2010-10-04 13:58 UTC (History)
4 users (show)

See Also:

Attachments

Description Anne 2009-10-01 13:43:01 UTC 
Should the status be changed before dispatching the error event? That would be more consistent with when the checking and downloading events are dispatched.

(I also get the feeling it would have been better if we had separate states for networking and the cache, but I guess that is not going to work at this point.)

It would be nice to have a note at step 7 ("If this was a cache attempt, discard cache group altogether.") that indicates this will change the state of the object the API talks against to UNCACHED.
Comment 1 Ian 'Hixie' Hickson 2009-10-18 23:39:48 UTC 
The status can't be changed to 'idle' until the last step, otherwise you'll have a race condition where two instances of the algorithm are running at once.

I've made the spec clearer that the tasks are expected to hold off until the next few steps are run also, though.

I didn't mention the API in the algorithm because it would be the only mention of it which seems kind of weird. Not sure what it would add. Please feel free to file another bug for that though if you feel strongly about it.
Comment 2 contributor 2009-10-18 23:40:16 UTC 
Checked in as WHATWG revision r4172.
Check-in comment: Get rid of a potential race condition in the cache update process.
http://html5.org/tools/web-apps-tracker?from=4171&to=4172