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