Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)

2010-04-29 Thread Jeremy Orlow
On Thu, Apr 29, 2010 at 6:01 PM, Boris Zbarsky  wrote:

> On 4/29/10 12:13 PM, Jeremy Orlow wrote:
>
>> The following script does not work for me in 3.6.  Would love to know
>> what I'm doing wrong:
>>
>> window.onstorage = function() { alert("HI"); }
>> localStorage.foo = localStorage.foo + " ";
>>
>
> In Gecko storage events for a change in window X are fired at all windows
> _except_ X that use that localStorage.
>
> This is in fact what the spec says to do.  See
> http://dev.w3.org/html5/webstorage/#localStorageEvent which says:
>
>  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, as described below.
>
> (emphasis added).


Ugh.  I'm an idiot.  I implemented this change in WebKit and even brought it
up on list.  :-)  Thanks for pointing it out.


>  I don't get anything on the error console or any alert.  (Though it
>> works in Safari and Opera.)
>>
>
> Sounds like some bugs need to be filed on Safari and Opera.
>

It's already changed in WebKit, so I suspect the next version of Safari will
be fixed.  Similarly, the next stable version of Chrome (which is about to
go to beta) does this.  And I just filed a bug against opera.


Anyway, I already have a patch out to change from uri -> url.  Sounds like
it's the right thing to do: https://bugs.webkit.org/show_bug.cgi?id=38331

J


Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)

2010-04-29 Thread Boris Zbarsky

On 4/29/10 12:13 PM, Jeremy Orlow wrote:

The following script does not work for me in 3.6.  Would love to know
what I'm doing wrong:

window.onstorage = function() { alert("HI"); }
localStorage.foo = localStorage.foo + " ";


In Gecko storage events for a change in window X are fired at all 
windows _except_ X that use that localStorage.


This is in fact what the spec says to do.  See 
http://dev.w3.org/html5/webstorage/#localStorageEvent which says:


  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, as described below.

(emphasis added).


I don't get anything on the error console or any alert.  (Though it
works in Safari and Opera.)


Sounds like some bugs need to be filed on Safari and Opera.

-Boris



Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)

2010-04-29 Thread Jeremy Orlow
On Thu, Apr 29, 2010 at 4:35 PM, Boris Zbarsky  wrote:

> On 4/29/10 9:23 AM, Jeremy Orlow wrote:
>
>> Opera 10.50 does return false for your bit of javascript, but when I
>> enumerate the properties on event after causing a storage event, "url"
>> is there.  Weird.
>>
>
> All that means is that the property is an own property of the object, not a
> property getter/setter pair on the prototype, no?
>
> It's interesting that you find this odd, given that this is exactly V8's
> behavior in general.  Compare:
>
>  alert("body" in HTMLDocument.prototype);
>  alert("body" in document");
>
> in your favorite HTML page.
>
>
>  My code did not work in Firefox 3.6.
>> https://developer.mozilla.org/en/DOM/Storage makes no mention of
>> StorageEvent.  Do they actually support events?
>>
>
> Sure seem to, with "url" as the property name.  Or at least there's
> definitely code in the tree to dispatch it when storage changes happen.
>

The following script does not work for me in 3.6.  Would love to know what
I'm doing wrong:

window.onstorage = function() { alert("HI"); }
localStorage.foo = localStorage.foo + " ";

I don't get anything on the error console or any alert.  (Though it works in
Safari and Opera.)


Re: StorageEvent.url (WAS: XMLHttpRequest.responseBlob)

2010-04-29 Thread Boris Zbarsky

On 4/29/10 9:23 AM, Jeremy Orlow wrote:

Opera 10.50 does return false for your bit of javascript, but when I
enumerate the properties on event after causing a storage event, "url"
is there.  Weird.


All that means is that the property is an own property of the object, 
not a property getter/setter pair on the prototype, no?


It's interesting that you find this odd, given that this is exactly V8's 
behavior in general.  Compare:


  alert("body" in HTMLDocument.prototype);
  alert("body" in document");

in your favorite HTML page.


My code did not work in Firefox 3.6.
https://developer.mozilla.org/en/DOM/Storage makes no mention of
StorageEvent.  Do they actually support events?


Sure seem to, with "url" as the property name.  Or at least there's 
definitely code in the tree to dispatch it when storage changes happen.


-Boris



StorageEvent.url (WAS: XMLHttpRequest.responseBlob)

2010-04-29 Thread Jeremy Orlow
On Thu, Apr 29, 2010 at 6:11 AM, Simon Pieters  wrote:
>
> You mean StorageEvent?
>
> javascript:alert('url' in StorageEvent.prototype)
>
> Opera: false
> Firefox: true
> Chrome: false
>

I tried actually causing a storage event and then enumerated its properties
with each browser and got somewhat different results.  Chrome/Safari are as
you say.  We call it "uri", but the last time it was changed was 2 years
ago, so I suspect this is just an artifact of an old version of the spec or
something.

Opera 10.50 does return false for your bit of javascript, but when I
enumerate the properties on event after causing a storage event, "url" is
there.  Weird.

My code did not work in Firefox 3.6.
https://developer.mozilla.org/en/DOM/Storage makes no mention of
StorageEvent.  Do they actually support events?

And IE also calls it a "url".  (But they put onstorage on the document
instead of the window.  And they have an onstoragecommit event as well.  Did
this stuff ever come up on list??)


So, in conclusion, I suppose WebKit should change uri to url to match the
rest of the world?

J