- From: Jared Morse <jarcoal@gmail.com>
- Date: Fri, 29 Jan 2010 11:13:25 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Olli@pettay.fi, public-webapps@w3.org
- Message-ID: <19e6d9a31001291113p1117b3b3p2b5e13383a376bae@mail.gmail.com>
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:14:01 UTC