- From: Drew Wilson <atwilson@google.com>
- Date: Sun, 8 Mar 2009 15:32:21 -0700
> > > document.cookies can't change in the middle of an execution. I.e. a script > like: > > a = document.cookie; > b = document.cookie; > alert(a === b); > > will always show 'true'. 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. What if I do something like this: a=document.cookie alert("now is the time to block our execution to allow HTTP requests to finish") b=document.cookie 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. Anyhow, I'm not averse to having an asynchronous API, but I'd still like to enable workers to do this: setCookie("cookiestring") xhr.send(); 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. -atw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090308/f359ffa2/attachment.htm>
Received on Sunday, 8 March 2009 15:32:21 UTC