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