Re: [whatwg] sessionStorage and the Storage event
Jonas Sicking wrote: On Mon, Oct 26, 2009 at 4:06 PM, Honza Bambas hon...@allpeers.com wrote: The spec says: When the setItem(), removeItem(), and clear() methods are called on a Storage 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 attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired, as described below. [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. Huh? Does documents from the same session not all share sessionStorage data? I.e. in the following set of events: 1. User navigates to http://example.com/a.html 2. Page sets sessionStorage.foo = hi; 3. User navigates, in same window, to http://example.com/b.html 4. Page sets sessionStorage.foo = saxophone; 5. User clicks back-button, which puts him back at http://example.com/a.html 6. Page does x = sessionStorage.foo; what is the value of 'x'? I would have expected it to be saxophone, is that not the case. This seems to be required in order to do for example multi-page forms. / Jonas Jonas, please read unique to its document as unique to its browsing context. I was wrong. In step 6 you'll get saxophone ;) -hb-
Re: [whatwg] sessionStorage and the Storage event
Ian Hickson wrote: On Tue, 27 Oct 2009, Honza Bambas wrote: 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. You can have multiple (active) documents sharing the same sessionHistory using nested browsing contexts, for example in iframe, object, and frameset/frame. s/sessionHistory/sessionStorage/ ? Ah, true. sessionStorage object is shared within the toplevel browsing context for all nested documents with the same origin. Then it makes sense to send the message to all those documents. Thanks for clarifying. -hb-
[whatwg] sessionStorage and the Storage event
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-
[whatwg] Should target '_search' be taken as part of HTML 5 spec?
Target '_search' makes a link open in a sidebar (Opera) or sidebar-like window (IE). For some offline web apps would be cool to open sidebar by just one click. In other browsers (Firefox) web content could be open in a sidebar only by creating a bookmark, marking it as to open in a sidebar, use (click) that bookmark. So, there are tendencies and voices to open web content in a sidebar in all browsers but it is not taken as a standard. I would really like this feature to be available in all browsers. Opinions? Honza Bambas
[whatwg] Should DOM storage objects be mapped by an effective script origin rather then just an origin?
See also mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=494799 Effective script origin driven by document.domain is used to allow sharing of properties and data among pages coming from different subdomains. Should this data sharing apply also to sessionStorage and localStorage? It means: having page load from http://test.mysite.com accessing sessionStorage would get sessionStorage bound to http://test.mysite.com. When that same page than changes document.domain to http://mysite.com, sessionStorage it gets now should be a different object, bound to http://mysite.com. A reason to do this is also because of security checking. The subject's origin changes to http://mysite.com and access to sessionStorage bound to http://test.mysite.com should not be allowed (origins are not equal). Opinions?
[whatwg] localStorage behavior when cookies mode is session-only
In the W3C spec for localStorage http://dev.w3.org/html5/webstorage/#the-localstorage-attribute is said to present it (the persistent storage) the same way as cookies. There were suggestion to throw DOM_QUOTA_ERROR exception when storing to localStorage in case when cookies are in a session-only mode for a host/page. It makes sense from several reasons. This way web apps may decide or inform user about situation that the page cannot store to localStorage while there is no way for the page to figure out that cookies mode is session-only and web app still may freely read from the storage. My suggestion is then: - allow a page to obtain valid localStorage object - allow read from it - throw DOM_QUOTA_ERROR when storing to it But I don't know what to do in case of call to clear() and removeItem() methods. It would exposes the cookie behavior again when it fails/throws. -hb-
[whatwg] Offline Cache iframe inheritance
The spec says when an iframe (a child browsing context) doesn't refer a manifest in the html tag it has to inherit cache from its parent's document. 1. This should be restricted to the same origin because when an offline application loads in an iframe a site (an advertisement or what ever site) that site has full access to window.applicationCache object and can inject to the cache any kind of resource from any origin without user notification. This resource is then carried among cache versions until explicitly overwritten or deleted from the cache. 2. When a completely different site from a different origin, in this case not malicious, is loaded in an iframe from inside of an offline application, the site would probably be completely broken - the resources on the page could not be load because of the associated cache of probably unrelated offline application. 3. Master documents are associated with the cache after the cache update finished. I percept this step as a way to make the offline application document be in a consistent state after cache update finished w/o need to refresh the top document, right? But, iframes that should inherit cache from its parents are not associated (there were no cache at moment of load/cache selection algorithm and there is not visible in the spec to do the association later). Workaround is to add reference to the manifest to all iframe'd documents, but in that case there is no need to have a special handling for such child contexts in case they don't refer a manifest. All these points lead me to opinion to remove the cache inheritance for child contexts feature. The manifest reference will not involve any new updates because they are atomically cumulated and let different sites fall off the offline app context. Also we don't have any cross-site security risks, even just potential. Potentially, to preserve inheritance and save some work to web developers, we may introduce explicit attribute to iframe by defining the manifest to use or just say to let the context inherit the cache from the parent. -hb-
Re: [whatwg] Opportunistic caching
Ian Hickson wrote: On Tue, 10 Jun 2008, Honza Bambas wrote: Hi, I would like to ask for clarification of opportunistic caching spec in Offline Web Applications, the article 4.9.1.9. Adding a resource whom URI matches an opportunistic name space seems to be done only for top level documents according to the article 4.9.1.9, cite: If the resource was not fetched from... where the resource refers, as I understand, the top-level document being navigated. I didn't find any other place where a resource whom URI matched an opportunistic entry would be added to a cache as opportunistically cached. I would naturally expect it were part of the networking model, article 4.7.5.1 - Changes to the networking model, but I couldn't find it, at least not explicitly, expressed. Maybe I am missing something in the networking model spec: in article 4.7.5.1.4 when URI matches a name space it have to be fetched normally. Should implementers replace normal HTTP cache used for writing by offline cache to store the resource in it? Instead of normal HTTP cache? Resources can only be cached as opportunistically cached entries if a browsing context is navigated, but it doesn't have to be a top-level browsing context. The caching happens in the Otherwise clause of step 9 of the 4.9.1 Navigating across documents navigation algorithm. If by top-level you don't mean a window/tab, but mean any iframe or frame content document, as opposed to an image, a stylesheet, or some such, then you are correct. The use case was really just replacing pages, e.g. Flickr pages, when the whole site isn't cached. Do you think this should be changed to opportunistically cache anything accessed? (Sorry for late answer, email has probably been lost...) Thanks a lot for clarification. I was talking with my colleague about it and we both agree it would be useful (and probably more easy to implement) for ANY resource being fetched inside of browsing context associated with an application cache to opportunistically cache it and not just do it for results of navigation, i.e. top-level document, iframe source and frame source. A set of pictures/icons/css styles could be easily cached this way w/o explicitly listing them in the manifest. At this point it would be good to say what really is intention/motivation of opportunistic caching itself. Maybe I am missing the purpose and potentially open a security hole or a kind of attack this way. Honza Bambas
[whatwg] Application cache update while browser in offline mode
When application cache update is invoked by document load that is completely fetched from offline application cache while the browser is in offline mode what exactly should happen? Let's say we always want to have one of the onxxx events on applicationCache object get called. In case the browser is in offline mode (including user switch to offline mode manually) the only reasonable event seems to be onerror call because the server could not actually be reached. The spec says nothing in particular about behavior of the update process while browser is offline. Thanks Honza Bambas
Re: [whatwg] Web Sockets
Ian Hickson wrote: Many years ago I wrote a draft for how to do full-duplex communication from a Web page. Over the years we've received much feedback on this TCPConnection API. I've now completely rewritten the relevant section and given it a new name, Web Sockets: http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#network If there are any security issues with this proposal, or if it fails to achieve its goals (discussed below), or fails to handle a case you care about, then please don't hesitate to send feedback to the list! I am just concern about the way the protocol is specified. When I read the notes it is obvious the communication is actually an HTTP communication. Let's say I am a browser developer. Let's say I have to enhance my already fully armed browser with all the support for HTTP protocol and proxy/HTTP authentication, cookies, fixed many security issues etc. It would be reasonable to use my HTTP implementation and build ws/wss client protocol on top of it. Problem is that spec counts with exact byte compare but my implementation might possibly change headers order or HTTP version (to higher one). This would violate the WHATWG spec but the request according to HTTP protocol would still be correct. This might make the implementation (and therefor also adoption) of this technology more complicated for browser developers. Why exactly is in the spec intention to do exact byte-to-byte match? To allow very easy implementation using scripts? Thanks -hb-
Re: [whatwg] Opportunistic caching
Ian Hickson wrote: On Tue, 10 Jun 2008, Honza Bambas wrote: Hi, I would like to ask for clarification of opportunistic caching spec in Offline Web Applications, the article 4.9.1.9. Adding a resource whom URI matches an opportunistic name space seems to be done only for top level documents according to the article 4.9.1.9, cite: If the resource was not fetched from... where the resource refers, as I understand, the top-level document being navigated. I didn't find any other place where a resource whom URI matched an opportunistic entry would be added to a cache as opportunistically cached. I would naturally expect it were part of the networking model, article 4.7.5.1 - Changes to the networking model, but I couldn't find it, at least not explicitly, expressed. Maybe I am missing something in the networking model spec: in article 4.7.5.1.4 when URI matches a name space it have to be fetched normally. Should implementers replace normal HTTP cache used for writing by offline cache to store the resource in it? Instead of normal HTTP cache? Resources can only be cached as opportunistically cached entries if a browsing context is navigated, but it doesn't have to be a top-level browsing context. The caching happens in the Otherwise clause of step 9 of the 4.9.1 Navigating across documents navigation algorithm. If by top-level you don't mean a window/tab, but mean any iframe or frame content document, as opposed to an image, a stylesheet, or some such, then you are correct. The use case was really just replacing pages, e.g. Flickr pages, when the whole site isn't cached. Do you think this should be changed to opportunistically cache anything accessed? Thanks a lot for clarification. I was talking with my colleague about it and we both agree it would be useful (and more easy to implement) for ANY resource being fetched inside of browsing context associated with an application cache to opportunistically cache it and not just do it for results of navigation, i.e. top-level document, iframe source and frame source. A set o pictures/icons/css styles could be easily cached this way w/o explicitly listing them in the manifest. At this point it would be good to say what really is intention/motivation of opportunistic caching itself. Maybe I am missing the purpose and potentially open a security hole or a kind of attack this way. Honza Bambas
