On Tue, Nov 3, 2009 at 6:36 AM, 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">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><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>
<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>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><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><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'm not convinced.  Look at Google Maps and street view.  Gmail uses more Flash now than it used to. </div></blockquote><div><br>For new features, sure. But are they reimplementing existing browser-based functionality to use plugins instead?<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"><br><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>
<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>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.<br>
<br clear="all">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>