<div class="gmail_quote">On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<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>What concerns me are the cases where synchronous events (e.g., resizing an iframe) can cause script to execute in another domain.  As spec'd, there is a potential dead lock with the storage mutex.  We must carefully unlock in situations like this.  However, such unlocking will appear quite mysterious to users, so much so that I question the value of the implicit storage mutex.</div>

</div></blockquote><div> </div></div><div>Right now I'm not sure how big a problem this actually is. The resize event for a document in a frame can surely be dispatched asynchronously so no unlocking is required. I would like to have a much better idea of how many places absolutely must release the storage mutex before deciding that approach is unworkable.<br>

</div></div><div><div></div><div class="h5"><br clear="all">Rob<br></div></div></blockquote><div><br></div><div><br></div><div>What about navigating an iframe to a reference fragment, which could trigger a scroll event?  The scrolling has to be done synchronously for compat with the web.</div>
<div><br></div><div>-Darin</div></div>