On Mon, Apr 6, 2009 at 7:03 PM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div class="im">On Fri, Apr 3, 2009 at 2:49 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div>On Sat, Apr 4, 2009 at 6:35 AM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@google.com" target="_blank">jorlow@google.com</a>></span> wrote:<br></div><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If I understood the discussion correctly, the spec for document.cookie never stated anything about it being immutable while a script is running.</blockquote></div><div><br>Well, there never was a decent spec for document.cookie for most of its life, and even if there had been, no implementations allowed asynchronous changes to cookies while a script was running (except for maybe during alert()) and no-one really thought about it. Was this even identified as a possible issue during Chrome development?</div>

</div></blockquote><div><br></div><div>In addition to alert(), don't forget about all the great state changing things that can happen to the cookie database (and other data stores) during a synchronous XMLHttpRequest (or synchronous document.load) in Firefox.  Maybe those are just bugs?  What if a Firefox extension wants to muck around with the cookie database while a web page is blocked on a synchronous XMLHttpRequest?  Maybe that should fail to avoid dead-locking?  Sounds like a recipe for flaky extensions since it is unlikely that the extension author would have been prepared for being called at this time when access to the cookie database would have to be denied.</div>
</div></div></blockquote><div><br>According to the spec the storage mutex is dropped for blocking operations like alert() and sync XHR, and as you know, that's effectively what we do.<br><br>But the general rule of DOM API design is that operations do not block and we offer asynchronous APIs instead. alert() and sync XHR are exceptions to this rule, but they're ugly stepchildren of DOM APIs and we don't want to treat them as norms.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div class="im"><div></div></div>When deciding how to handle cookies in Chrome, we did not worry about the problem being debated here.  Our concerns were allayed by recognizing that IE does not try to solve it (and IE6 is multi-process just like Chrome with a shared network stack), so clearly web developers must already have to cope.</div>
</blockquote><div><br>You mean IE8.<br><br>How would Web developers cope? There's no way to synchronize. I doubt more than a handful of Web developers even know this problem could exist.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">I think it would be best to specify that document.cookie returns a snapshot.  I think that is consistent with existing implementations including IE, Firefox, and Chrome.</div></blockquote><div><br>
Not at all. In Firefox, cookies don't change while a script is running, as long as it doesn't call the handful of blocking DOM APIs (such as alert() or sync XHR); we satisfy the current spec.<br><br>The insidious part is that almost all the time, IE and Chrome will also be observed to obey the spec; when a quick cookie-read-modify-write script runs, it is very unlikely cookies will change underneath it. (Is it possible people don't write such scripts?)<br>
<br>Maybe we need dynamic race detection for Web browsers. After a script reads document.cookie, stall for a while to give network transactions or scripts running in other threads a chance to change the cookies so the original script carries on with wrong data.<br>
</div></div><br>Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>