Ah, well then I think your suggestion would be ideal. -J
On Fri, Jan 29, 2010 at 11:25 AM, Jeremy Orlow 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-proce
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 wrote:
> That would be a good solution in my opinion,
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 expect
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 wrote:
> Hi Jeremy, your patch (https://bugs.webkit.org/show_bug.cgi?id=30546) is
> actually what brought this to my attenti
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
On Thu, Jan 28, 2010 at 3:38 PM, Olli Pettay wrote:
> On 1/29/10 12:22 AM, Jared Morse 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.
>
> Well you could do something like
> Storage.prototype.s
On 1/29/10 12:22 AM, Jared Morse 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.
Well you could do something like
Storage.prototype.setItemAndNotify =
function (key, data) {
this.setItem(key, d
On Thu, Jan 28, 2010 at 2:22 PM, Jared Morse 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 yo
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.
-J
On Thu, Jan 28, 2010 at 2:06 PM, Olli Pettay wrote:
> On 1/28/10 11:57 PM, Jared Morse wrote:
>
>> Even though it occurs on the same document, doesn't mean
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
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
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
metho
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 HTMLDocu
13 matches
Mail list logo
