W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: localStorage Event

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 29 Jan 2010 11:25:51 -0800
Message-ID: <5dd9e5c51001291125n21958807s60a736912f0d8c04@mail.gmail.com>
To: Jared Morse <jarcoal@gmail.com>
Cc: Olli@pettay.fi, public-webapps@w3.org
The source parameter was taken out of the spec for a while ago.  And it
never worked in Chrome because the window may be in another process (and we
don't handle/allow cross-process scripting).

J

On Fri, Jan 29, 2010 at 11:13 AM, Jared Morse <jarcoal@gmail.com> wrote:

> That would be a good solution in my opinion, although if you wanted to
> check if the event was dispatched by the current document or another, I
> believe you could use the source property that the spec currently contains,
> and just do something like:
>
> ev.source == window ?
>
> That seems to work as expected in Safari 4.0.4 (I assume production builds
> of Chrome as well).
>
> -J
>
>
> On Fri, Jan 29, 2010 at 10:36 AM, Jeremy Orlow <jorlow@chromium.org>wrote:
>
>> We could change it to fire in all windows and have a boolean that says
>> whether you fired it.  Maybe that's the best solution?
>>
>>
>> On Fri, Jan 29, 2010 at 10:33 AM, Jared Morse <jarcoal@gmail.com> wrote:
>>
>>> Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is
>>> actually what brought this to my attention.
>>>
>>> I cannot think of an example where iframe's would not be sufficient as a
>>> work-around, however it could potentially be inconvenient to use them,
>>> especially when your app may be open in several tabs.  Each other tab would
>>> get two events triggered, one for the primary document and one for the
>>> iframe inside of it.  While this isn't the end of the world, clearly you
>>> would need to always check the source of the iframe event, to make sure it
>>> came from it's parent, and not another tab.
>>>
>>> Between this and Olli's prototype suggestion, it is clear there are
>>> definitely ways around this issue should a developer face it.  However, I do
>>> think the advantage of having your "glue" code written for you would be of
>>> great benefit to developers.
>>>
>>> -J
>>>
>>>
>>> On Thu, Jan 28, 2010 at 3:06 PM, Jeremy Orlow <jorlow@chromium.org>wrote:
>>>
>>>> On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse <jarcoal@gmail.com> wrote:
>>>>
>>>>> Perhaps I am mistaken, but I believe you would still have to go around
>>>>> and add that trigger to all the places the value is changed from.
>>>>>
>>>>
>>>> That is true.
>>>>
>>>> Can you give some clear examples of when having local storage events
>>>> being fired in your frame would be useful?  Bonus points if they're
>>>> something that can't be handled by simply creating an iframe within your doc
>>>> and using it to monitor events (which is the obvious work-around).
>>>>
>>>> J
>>>>
>>>>
>>>>> On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
>>>>>
>>>>>> On 1/28/10 11:57 PM, Jared Morse wrote:
>>>>>>
>>>>>>> Even though it occurs on the same document, doesn't mean loosely
>>>>>>> coupled
>>>>>>> code can't benefit from it.
>>>>>>>
>>>>>>> Imagine if each time you added a feature to a web app that depended
>>>>>>> on
>>>>>>> knowing a current value from the storage, you'd have to go around to
>>>>>>> all
>>>>>>> the places that value is changed and add some code to alert your new
>>>>>>> code.  If storage events triggered on the same document, all you
>>>>>>> would
>>>>>>> have to do is set a listener.
>>>>>>>
>>>>>>
>>>>>> If you really need this behavior, you can always dispatch your own
>>>>>> event
>>>>>> to the window when you change the data.
>>>>>>
>>>>>>
>>>>>> -Olli
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -J
>>>>>>>
>>>>>>> On Thu, Jan 28, 2010 at 1:41 PM, Olli Pettay <
>>>>>>> Olli.Pettay@helsinki.fi
>>>>>>> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>>>>>>>
>>>>>>>    On 1/28/10 9:34 PM, Jared Morse wrote:
>>>>>>>
>>>>>>>        Hi, I have a concern about the web storage event spec
>>>>>>>        (http://dev.w3.org/html5/webstorage/).
>>>>>>>
>>>>>>>        The spec states:
>>>>>>>        "When the setItem(), removeItem(), and clear()  methods are
>>>>>>>        called on a
>>>>>>>        Storage object x that is associated with a local storage area,
>>>>>>>        if the
>>>>>>>        methods did something, then in every HTMLDocument object whose
>>>>>>>        Window
>>>>>>>        object's localStorage attribute's Storage object is associated
>>>>>>>        with the
>>>>>>>        same storage area, other than x, a storage event must be
>>>>>>> fired..."
>>>>>>>
>>>>>>>        My concern lies with the "other than x" part.  Unless I'm
>>>>>>> missing
>>>>>>>        something, these events would be even more useful if they also
>>>>>>>        fired in
>>>>>>>        the HTMLDocument that initially made the storage call.
>>>>>>>
>>>>>>>
>>>>>>>    The page which is changing storage object knows already that the
>>>>>>>    storage object is being changed. Why would it need explicit
>>>>>>>    notification (event) about that?
>>>>>>>
>>>>>>>
>>>>>>>    -Olli
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>        Thanks for your time.
>>>>>>>
>>>>>>>        -Jared
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Received on Friday, 29 January 2010 19:26:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT