<div class="gmail_quote">On Mon, Nov 2, 2009 at 3:46 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 Tue, Nov 3, 2009 at 6:36 AM, 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">1a) Given a page (domain A) containing an iframe (domain B), have the outer page navigate the inner frame to "about:blank".  This navigation completes synchronously, and the unload handler for the iframe runs before the navigation request completes.  This is true of all browsers.
<div><br></div><div>1b) Suppose the inner page has a pending XMLHttpRequest when the outer frame navigates the inner frame.  The XHR's onabort handler would run before the navigation to "about:blank" completes.</div>

</div></blockquote></div><div><br>These are really the same problem: synchronous cross-domain about:blank navigation. If navigation to about:blank has to be synchronous, then I guess it needs to drop the lock, at least in the cross-domain case.<br>
</div></div></blockquote><div><br></div><div>That's correct.  My point is simple:  Here is another case where nesting can happen that hadn't been foreseen.  Trying to foresee all such issues is difficult.</div><div>
<br></div><div>Will we just keep amending the spec each time we find such a possible case?</div><div><br></div><div>I think it is far saner to say that any nesting leads to unlocking the storage mutex.  The spec can then list cases where this nesting might occur.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
<br></div><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>2) Set a break point in the Mozilla JS debugger.  This runs a nested event loop each time you single step so that it can drive the rest of the browser UI.</div><div><br></div><div>3) Install a Firefox extension that runs a nested event loop in response to an event generated by content.  I debugged many Firefox crashes resulting from extensions that do this kind of thing for various reasons.</div>

</div></blockquote></div><div><br>These are internal Mozilla issues and should not be allowed to influence the design of the Web platform. They'll probably change for multi-process anyway.<br></div></div></blockquote>
<div><br></div><div>OK, but my point is that the spec should afford implementors with the ability to unlock the storage mutex at other times for reasons not mentioned in the spec.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><br></div><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">I'm not convinced.  Look at Google Maps and street view.  Gmail uses more Flash now than it used to. </div></blockquote></div><div><br>For new features, sure. But are they reimplementing existing browser-based functionality to use plugins instead?<br>
</div></div></blockquote><div><br></div><div>I think it is sufficient to just talk in the context of new features.  A JS library or component grows a new feature that suddenly starts using a plugin.  Now, API calls that were not supposed to touch plugins start touching plugins, and the storage mutex gets dropped.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
<br></div><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"><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>
<br></div><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">What will you do for Gecko when it supports content processes?<br>



</div></blockquote></div></div><br clear="all">Implement the spec, I hope!</blockquote><div><br></div></div><div>It seems odd to me that this behavior was put into the spec without any implementation experience to guide it.  The only multi-process implementations that I know of do not have a storage mutex.</div>

</div></blockquote><br></div></div>Lots of things are in the spec without implementation experience. I think we have time to collect more experience on this issue with multi-process browsers and revise the spec in light of it.<div>
<div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>OK.  Please note my objection to the storage mutex.</div><div><br></div><div>-Darin</div></div>