On Tue, Sep 8, 2009 at 6:38 PM, Aaron Boodman <span dir="ltr"><<a href="mailto:aa@google.com">aa@google.com</a>></span> wrote:<br><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">On Tue, Sep 8, 2009 at 2:02 AM, Robert O'Callahan<<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>> wrote:<br>
</div><div class="im">> Looking back over previous threads on the storage mutex, I can't seem to<br>
> remember or find the reason that implementing the storage mutex for cookies<br>
> can't easily be done with a mutex per domain. Ian pointed out this approach<br>
> breaks if you can make synchronous script calls across origins (e.g. across<br>
> IFRAME boundaries), but can you actually make such calls? Or if you can<br>
> (NPAPI?), can we just declare that those APIs release the storage mutex?<br>
<br>
</div>I believe that synchronous cross-origin calls are possible a variety<br>
of ways. Here is one way I found with a quick test: Resize an iframe<br>
element. window.onresize is fired synchronously inside the frame. I<br>
bet there are others.<br>
<div class="im"><br>
> I know that setting document.domain makes this tricky because it<br>
> synchronously enables new cross-domain interactions, but can't we handle<br>
> that by declaring that setting document.domain releases the storage mutex?<br>
<br>
</div>All of these different ways that the storage mutex gets implicitly<br>
released lead to weird behavior in edge cases. In my opinion, it would<br>
be better to fix the API in a clean way than keep patching it like<br>
this.<br></blockquote><div><br></div><div>I definitely agree.  Implicitly releasing the lock is terrible.  (We should at the _very least_ create some way for people to know when it's been implicitly released!)</div></div>