W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2009

[whatwg] sessionStorage and the Storage event

From: Honza Bambas <honzab@allpeers.com>
Date: Tue, 27 Oct 2009 00:06:41 +0100
Message-ID: <4AE62B81.8000700@allpeers.com>
The spec says:

"When the |setItem() 
<http://dev.w3.org/html5/webstorage/#dom-storage-setitem>|, 
|removeItem() 
<http://dev.w3.org/html5/webstorage/#dom-storage-removeitem>|, and 
|clear() <http://dev.w3.org/html5/webstorage/#dom-storage-clear>| 
methods are called on a |Storage 
<http://dev.w3.org/html5/webstorage/#storage-0>| object x that is 
associated with a session storage area, if the methods did something, 
then in every |HTMLDocument| object whose |Window| object's 
|sessionStorage 
<http://dev.w3.org/html5/webstorage/#dom-sessionstorage>| attribute's 
|Storage <http://dev.w3.org/html5/webstorage/#storage-0>| object is 
associated with the same storage area, other than x, a |storage 
<http://dev.w3.org/html5/webstorage/#event-storage>| event must be 
fired, as described below 
<http://dev.w3.org/html5/webstorage/#event-storage>."

[http://dev.w3.org/html5/webstorage/#dom-sessionstorage]

The same applies to localStorage.

Maybe I read something wrong, but as a sessionStorage object is always 
unique to its document (it is cloned when a new document with the same 
origin is created and then independent from the original document's 
object) it, in my opinion, doesn't make sense to send the event to any 
other document then the one its storage has been changed. On the other 
hand, it makes sense to me to not fire the event in the same document 
where the storage has been changed (as for localStorage), then, I'd say 
there should be no event for sessionStorage at all. I simply don't a 
case when two or more documents would share a single sessionStorage object.

Thanks for clearing this.

-hb-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091027/328ed3ee/attachment.htm>
Received on Monday, 26 October 2009 16:06:41 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC