- From: Darin Fisher <darin@chromium.org>
- Date: Tue, 3 Nov 2009 09:51:33 -0800
On Mon, Nov 2, 2009 at 3:46 PM, Robert O'Callahan <robert at ocallahan.org>wrote: > On Tue, Nov 3, 2009 at 6:36 AM, Darin Fisher <darin at chromium.org> wrote: > >> 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. >> >> 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. >> > > 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. > 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. Will we just keep amending the spec each time we find such a possible case? 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. > > 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. >> >> 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. >> > > 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. > 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. > > I'm not convinced. Look at Google Maps and street view. Gmail uses more >> Flash now than it used to. >> > > For new features, sure. But are they reimplementing existing browser-based > functionality to use plugins instead? > 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. > > >> >>> What will you do for Gecko when it supports content processes? >>>> >>> >>> Implement the spec, I hope! >> >> >> 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. >> > > 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. > > OK. Please note my objection to the storage mutex. -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091103/ed1d0407/attachment-0001.htm>
Received on Tuesday, 3 November 2009 09:51:33 UTC