[whatwg] localStorage feedback

[Jeremy Orlow]

On Tue, Nov 3, 2009 at 9:51 AM, Darin Fisher <darin at chromium.org> wrote:

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

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

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.

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

And mine.  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091103/06a4d5df/attachment-0001.htm>