Re: localStorage Event

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