[whatwg] localStorage feedback

[Darin Fisher]

On Mon, Nov 2, 2009 at 1:28 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Sun, Nov 1, 2009 at 3:53 AM, Darin Fisher <darin at chromium.org> wrote:
>
>> On Fri, Oct 30, 2009 at 1:36 AM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> On Fri, Oct 30, 2009 at 7:27 PM, Darin Fisher <darin at chromium.org>wrote:
>>>
>>>> You are right that the conditions are specific, but I don't know that
>>>> that is the
>>>> exhaustive list.  Rather than defining unlock points, I would implement
>>>> implicit
>>>> unlocking by having any nested attempt to acquire a lock cause the
>>>> existing lock
>>>> to be dropped.  Nesting can happen in the cases you mention, but
>>>> depending on
>>>> the UA, it may happen for other reasons too.
>>>>
>>>
>>> What reasons?
>>>
>>> If these reasons are situations where it's fundamentally difficult,
>>> impossible, or non-performant to follow the spec, we should change the spec.
>>> Otherwise this would just be a bug in the UA.
>>>
>>
>> My point is that it is difficult to ensure that all situations where
>> nesting can occur are understood apriori and that the list doesn't change
>> over time.  Because we are talking about multi-threading synchronization in
>> a very complex system, I would much prefer a more isolated and less fragile
>> solution.
>>
>> Unlock if yieldForStorageUpdates is called.
>> Unlock when returning from script execution.
>> Unlock if another attempt to lock occurs (any form of nesting).
>>
>> In the third case, I'd probably log something to the JS console to alert
>> developers.
>>
>> I believe this simple implementation covers most of the cases enumerated
>> in the spec, and it has the property of being easier to reason about and
>> easier to support (more future proof).
>>
>
> I think this would make the spec too dependent on implementation details.
> If your implementation needlessly or accidentally "nests" script execution
> --- e.g. by firing an event synchronously that should be, or could be,
> asynchronous --- then you'd still conform to your spec while the behaviour
> you present to authors gets quietly worse.
>
> If your description is (or can be, after suitable modifications) equivalent
> to what the spec currently says, but the equivalence is subtle (which it
> would be!), then I think they should *both* be in the spec, and the spec
> should say they're equivalent. Then if we find they're not equivalent, we
> clearly have a bug in the spec which must be fixed --- not carte blanche to
> proceed in an undesirable direction. It would be a sort of spec-level
> assertion.
>

I think the spec currently calls attention to only some situations that
could lead to nesting of implicitly acquired storage locks.

I previously described some other situations, which you and others indicated
should be treated as WebKit and IE bugs.  I didn't look very far to dig
those up.  After some more thought, I came up with these additional cases
that the spec doesn't cover:

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.

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.




>
>
>>
>>>
>>> For example, a JS library might evolve to use flash for something small
>>>> (like
>>>> storage or sound) that it previously didn't use when I first developed
>>>> my code.
>>>> Voila, now my storage lock is released out from under me.
>>>>
>>>
>>> This example still sounds overly contrived to me. Nevertheless, it seems
>>> strange to say that because there might be a few unexpected race conditions,
>>> you have decided to allow a much larger set of unexpected race conditions.
>>>
>>
>> Why is it contrived?
>>
>
> Because libraries tend to initially use plugins and move towards using core
> browser functionality, not the other way around. But even if these library
> issues aren't contrived, I don't see how they justify making things a lot
> more unpredictable for everyone.
>

I'm not convinced.  Look at Google Maps and street view.  Gmail uses more
Flash now than it used to.  Wave uses Gears for a variety of little things.
 There's a cool video gadget that swaps between HTML5 video or Flash
depending on the browser and the target media.



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

-Darin



>
> 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/20091102/8e8c35d0/attachment-0002.htm>