So an asynchronous cookie setting API would look like:<br><br>setCookie(cookieStr, callback)<br><br>...where the callback is invoked once the cookie has been set?<br><br>I guess I don't yet entirely understand the implementation details - it sounds like there are problems accessing any shared state between workers and window context?<br>
<br>-atw<br><br><div class="gmail_quote">On Thu, Mar 5, 2009 at 5:35 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Thu, Mar 5, 2009 at 5:33 PM, Michael Nordman <<a href="mailto:michaeln@google.com">michaeln@google.com</a>> wrote:<br>
> On Thu, Mar 5, 2009 at 5:23 PM, Michael Nordman <<a href="mailto:michaeln@google.com">michaeln@google.com</a>> wrote:<br>
>>> Allowing cookie to be set would unfortunately create a synchronous<br>
>>> communication channel between the worker and the main window. This is<br>
>>> something that we need to avoid to prevent users from having to deal<br>
>>> with locking and other thread related issues.<br>
>><br>
>> Hmmm... the cookie setting API could be async in workers.<br>
><br>
> In the absence of providing such an API, one exists (provided network<br>
> connectivity) indirectly in the form the XHR... ask the server to<br>
> either read or set cookies values for you.<br>
<br>
</div></div>Gecko, and I believe the latest XHR spec drafts, have disabled access<br>
to cookies through XHR in order to prevent leaking of HTTPOnly<br>
cookies.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br>