W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] localStorage feedback

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 3 Nov 2009 12:46:13 +1300
Message-ID: <11e306600911021546wdc2e241ua29b307c10507b2a@mail.gmail.com>
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.

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.

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?


>
>> 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.

Rob
-- 
"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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091103/3d128139/attachment.htm>
Received on Monday, 2 November 2009 15:46:13 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC