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

Re: localStorage Event

From: Jared Morse <jarcoal@gmail.com>
Date: Fri, 29 Jan 2010 11:39:11 -0800
Message-ID: <19e6d9a31001291139q44ffbefehfe9a5cd65218a9c@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Olli@pettay.fi, public-webapps@w3.org
Ah, well then I think your suggestion would be ideal.  -J

On Fri, Jan 29, 2010 at 11:25 AM, Jeremy Orlow <jorlow@chromium.org> wrote:

> 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:39:44 GMT

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