[whatwg] Storage events

[Ian Hickson]

On Thu, 15 Oct 2009, Jeremy Orlow wrote:
>
> I'd like to propose we remove the "source" attribute from storage 
> events.  ( http://dev.w3.org/html5/webstorage/#the-storage-event) In 
> Chrome, we cannot provide access to a window object unless it's in the 
> same process.  Since there's no way to guarantee that two windows in the 
> same origin are in the same process, Chrome would need to always set it 
> to null in order to avoid confusing developers (since what process a 
> page is in is really an implementation detail).
>
> But, as far as I can tell, Safari is the only browser that currently 
> provides this.  I suspect that as other multi-process implementations 
> are developed, they'll run into the same issue.  And, even if they can 
> technically provide synchronous access to another processes Window 
> object, there are _very_ strong arguments against it.  So, can we please 
> remove the source attribute from storage events?

On Thu, 15 Oct 2009, João Eiras wrote:
> 
> The specification tells source is a WindowProxy, so if the underlying 
> window is deleted, or inaccessible, accessing any member of source could 
> just throw an INVALID_STATE_ERR. The problem is there also if a storage 
> event is queued and the originating window is deleted meanwhile, or the 
> document with the listener keeps a reference to the originating window 
> for a long time, and that window is closed, unless the user agent keeps 
> the originating window live while it's WindowPRoxy is not garbage 
> collected, which is not desirable.

I've removed the 'source' attribute.


On Thu, 15 Oct 2009, Maciej Stachowiak wrote:
> 
> I would guess the main use case for this is to distinguish changes from 
> *this* window (the one receiving the event) and changes from other 
> windows. Perhaps a boolean flag to that effect could replace source.

I haven't added this currently, but we may add this in the future if it 
turns out to be useful.


On Thu, 15 Oct 2009, Jeremy Orlow wrote:
> 
> One other question: is the URL attribute supposed to be the same as 
> documentURI or location.href?  I ask because WebKit currently uses the 
> documentURI but if this were the correct behavior, I would have expected 
> the spec to make that more clear.

The spec is completely explicit about what it should be set to -- it says:

# the event must have its url attribute set to the address of the document 
# whose Storage object was affected
 -- http://www.whatwg.org/specs/web-apps/current-work/complete.html#event-storage

...where "the address of the document" is defined as being the same as the 
value returned by document.URL (which is different than the value returned 
by location.href -- that's "the document's current address"). If you 
follow the hyperlinks from the link above, and click on the bold <dfn> 
text to find where the terms are used, you should find it to be 
unambiguous.


On Thu, 15 Oct 2009, Darin Fisher wrote:
> 
> This is interesting since documentURI is a read/write property: 
> http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI

I assume that is a mistake. Does anyone support documentURI? It seems 
completely redundant with document.URL.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'