<div class="gmail_quote">On Tue, Nov 3, 2009 at 9:51 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.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="gmail_quote"><div class="im">On Mon, Nov 2, 2009 at 3:46 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org" target="_blank">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>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>
<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><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 class="im">
<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><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><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></blockquote><div><br></div>
<div>If we do this, we need to re-visit ways that scripts can tell whether the lock has been dropped. I can't remember which idea was most in favor last time we talked about it, but a counter that increments every time LocalStorage is unlocked sticks out in my mind. (Scripts can check the counter, do something that could cause unlocking, and then verify the counter is still the same after.) Another option that just came to mind is to have some flag that says "throw an exception whenever there's been a serialization violation".</div>
<div><br></div><div>Just to be clear for those following along at home: If we (Chrome) implement the storage mutex for the next version of Chrome, it'll have to be the way Darin's describing (mainly for schedule based reasons). It would be nice to eventually fix all the cases that cause unnecessary unlocking, but that's going to take a while.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><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><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><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 class="im">
<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><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><br></div></div></blockquote><div><br></div></div><div>OK. Please note my objection to the storage mutex.</div></div></blockquote><div><br></div><div>And mine. :-)</div></div>