<div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
</div>document.cookies can't change in the middle of an execution. I.e. a script like:<br>
<br>
a = document.cookie;<br>
b = document.cookie;<br>
alert(a === b);<br>
<br>
will always show 'true'.</blockquote><div><br></div><div>Is that strictly true? Can you point me to the appropriate part of the spec, because I couldn't find anything relevant other than what I previously quoted, and that doesn't seem to make any guarantees for the stability of document.cookies (perhaps the spec itself needs to be clarified to provide those guarantees?). Guaranteeing that relationship seems to imply that we ignore cookies set by network calls that happen in parallel with the current thread of javascript execution.</div>
<div><br></div><div>What if I do something like this:</div><div><br></div><div>a=document.cookie</div><div>alert("now is the time to block our execution to allow HTTP requests to finish")</div><div>b=document.cookie</div>
<div><br></div><div>Is a===b still guaranteed to be true (maybe so)? It's assuredly *not* guaranteed to be true if you swap out that alert with a synchronous xhr.</div><div><br></div><div>Anyhow, I'm not averse to having an asynchronous API, but I'd still like to enable workers to do this:</div>
<div><br></div><div>setCookie("cookiestring")</div><div>xhr.send();</div><div><br></div><div>Forcing workers to do all of their cookie-laden network requests via a double-callback (set cookie, wait for callback, invoke xhr, wait for response) seems too cumbersome.</div>
<div><br></div><div>-atw</div></div><br></div>