Re: [whatwg] Storage events
On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: 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. We implement it in Gecko. We even implement the setter, here: http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#5844 :) / Jonas
Re: [whatwg] Storage events
On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: ... 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. Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. Huh? So WebKit effectively have one of the main features of pushState already? Does the URL-bar change? Does the referrer change for subsequent requests such as navigation? I'm guessing it doesn't hook the back-button the way that pushState does though. / Jonas
Re: [whatwg] Storage events
On Sat, Oct 17, 2009 at 11:58 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: ... 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. Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. Huh? So WebKit effectively have one of the main features of pushState already? Does the URL-bar change? Does the referrer change for subsequent requests such as navigation? I'm guessing it doesn't hook the back-button the way that pushState does though. / Jonas It appears to impact the baseURL for the document. -Darin
Re: [whatwg] Storage events
On Sun, Oct 18, 2009 at 2:53 AM, Darin Fisher da...@chromium.org wrote: On Sat, Oct 17, 2009 at 11:58 PM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote: Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. Huh? So WebKit effectively have one of the main features of pushState already? Does the URL-bar change? Does the referrer change for subsequent requests such as navigation? I'm guessing it doesn't hook the back-button the way that pushState does though. / Jonas It appears to impact the baseURL for the document. WebKit's behavior of documentURI was my attempt to reconcile the DOM spec with security and reality. Previously, WebKit actually let you assign the internal representation of the documentURI, which was obviously disaster from a security point of view. Adam
Re: [whatwg] Storage events
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Storage events
On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: ... 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. Gecko and WebKit appear to both support documentURI. Only WebKit allows it to be modified. -Darin
[whatwg] Storage events
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? 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.
Re: [whatwg] Storage events
On Oct 15, 2009, at 11:37 AM, 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). 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. - Maciej 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? 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.
Re: [whatwg] Storage events
On Thu, 15 Oct 2009 20:37:48 +0200, Jeremy Orlow jor...@chromium.org 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). 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. So, I support Jeremy's suggestion. source should probably be removed from the spec. Which are its use cases anyway ?
Re: [whatwg] Storage Events for a Specific Storage Area
On Wed, 17 Jun 2009, Joseph Pecoraro wrote:
The storage event [1] fires for both sessionStorage and localStorage.
To me, this means if you only want to interact with localStorage you
will have to manually ensure that it is the storage area being modified:
window.addEventListener('storage', function(e) {
if ( e.storageArea === localStorage ) {
// ...
}
}
Was there any discussion about creating events specific to the storage
object, or should that already be possible? I've been playing around
with WebKit's Storage implementation, and the following (understandably)
is not possible:
localStorage.addEventListener
undefined
Is there any way to listen to events for a single specific storage area
or is the previously mentioned approach preferred?
We could make Storage into an EventTarget and also fire events on there,
sure. As Jeremy said, this is something that might best be done in the
next version; we're still trying to get the current features implemented
in a stable and consistent fashion as it is.
In general, though, I don't think it's critical, since you can easily work
around it by checking which was changed based on the event data.
(I agree that your proposal would have made more sense. I'm sorry my
learning experiences have such a detrimental effect on the Web! :-) )
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Storage Events for a Specific Storage Area
We could make Storage into an EventTarget and also fire events on there, sure. As Jeremy said, this is something that might best be done in the next version; we're still trying to get the current features implemented in a stable and consistent fashion as it is. Sounds great. Although wouldn't now be the best time to introduce something new? Its not a breaking change (theoretically), its an additional feature. Its my understanding that most of Web Storage is undergoing changes (B-trees and SQL orthogonally), but the Storage interface is not going to change much? Is that because of current browser support? In general, though, I don't think it's critical, since you can easily work around it by checking which was changed based on the event data Fair enough. =) (I agree that your proposal would have made more sense. I'm sorry my learning experiences have such a detrimental effect on the Web! :-) ) We're all learning. =P -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.' - Joe
Re: [whatwg] Storage Events for a Specific Storage Area
This doesn't break anything in the current spec. So it wouldn't break any existing implementations. I'm also guessing that the groundwork for implementing a feature like this is already in place due to the ubiquity of addEventListener. To be frank, it seems like a lot of bloat though to avoid a simple comparison. Its my thinking that the simple comparison shouldn't be necessary to begin with. Thats why I suggested this. This is a probably a bad analogy, but would it make sense to put a click function on just the window object and check every time it fires to see if it fired in the div you were interested in? Imagine every single click listener you register fires every time you click on something... that doesn't scale. (The reason this is a bad is because these click events bubble. Maybe bubbling is appropriate here)? - Less Listener Functions Fired - Instead of every registered listener getting fired on every storage event, only those applicable will be fired. This may mean overall less listeners getting fired, and code that doesn't have to continually check the affected storageArea, leading to potential performance improvements. Actually, assuming only one of the two solutions would exist the same amount of events would fire. A change to localStorage causes an event to be dispatched and likewise a change to sessionStorage causes an event to be dispatched. Having said that, with your solutions more events will fire since the legacy event will have to be dispatched too. What do you mean when you say more events will fire? Why not just fire the same storage event but now put the if statement that the web developer had to always write and put it into the browser's dispatching code. This may be my inexperience with the implementations, but I honestly don't see how this could end up firing more events. I think looking at it this way (more events) is looking at it sideways and maybe a bit pessimistically. If my first thought is this is going to be really complex then my next thought is how can I simplify this and if I can't find a way to simplify it I would state why it can't or shouldn't be done. I don't see that here, I just see the this is really complex part. I'm guessing that there is a simpler way to look at this, and if not I'd be interested to know why this seems so complex. - Joe
Re: [whatwg] Storage Events for a Specific Storage Area
On Mon, 22 Jun 2009 18:45:34 +0200, Jeremy Orlow jor...@chromium.org wrote: Seems like a reasonable idea. I don't know if it's been brought up before. My guess is that Ian will say this should be re-examined for HTML6, though. Seems like that would be a bit too late; given existing deployment I don't expect changes to this to be within the realm of possibilities. By the way, change requests for this specification should be made to public-weba...@w3.org. localStorage and friends are no longer part of HTML5. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Storage Events for a Specific Storage Area
Is it too late? It seems as though Joseph's suggestion could be in addition to what's already in the spec. On Tue, Jun 23, 2009 at 2:54 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 22 Jun 2009 18:45:34 +0200, Jeremy Orlow jor...@chromium.org wrote: Seems like a reasonable idea. I don't know if it's been brought up before. My guess is that Ian will say this should be re-examined for HTML6, though. Seems like that would be a bit too late; given existing deployment I don't expect changes to this to be within the realm of possibilities. By the way, change requests for this specification should be made to public-weba...@w3.org. localStorage and friends are no longer part of HTML5. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Storage Events for a Specific Storage Area
Jeremy Orlow: Is it too late? It seems as though Joseph's suggestion could be in addition to what's already in the spec. This doesn't break anything in the current spec. So it wouldn't break any existing implementations. I'm also guessing that the groundwork for implementing a feature like this is already in place due to the ubiquity of addEventListener. Pros: - Less Developer Confusion: When a web developer is focusing on a particular Storage area and set a storage listener, unless they check the storageArea they may not realize their listener is getting fired for scripts dealing with a different Storage area. I'm not sure if this can be considered a security threat but it would certainly limit the potential for problems. - Less Listener Functions Fired - Instead of every registered listener getting fired on every storage event, only those applicable will be fired. This may mean overall less listeners getting fired, and code that doesn't have to continually check the affected storageArea, leading to potential performance improvements. Cons: - This is similar to implementing the full EventTarget Interface on Storage areas. However, the only event of importance on a Storage area is storage not click or hover etc. Invalid event types should probably throw an error or something... or maybe this is more in the scope of DOM Events. Anne: By the way, change requests for this specification should be made to public-weba...@w3.org. localStorage and friends are no longer part of HTML5. I read from your (Anne's) blog that Web Storage has split off of HTML5, and I see it on the WebApps homepage [1] but the document itself said to send feedback to either mailing list or the bugzilla [2]. I just subscribed. In the future I'll use the other list for whats on the WebApps homepage. [1]: http://www.w3.org/2008/webapps/charter/ [2]: http://dev.w3.org/html5/webstorage/#status-of-this-document - Joe
Re: [whatwg] Storage Events for a Specific Storage Area
On Tue, 23 Jun 2009 19:51:18 +0200, Joseph Pecoraro joepec...@gmail.com wrote: Jeremy Orlow: Is it too late? It seems as though Joseph's suggestion could be in addition to what's already in the spec. This doesn't break anything in the current spec. So it wouldn't break any existing implementations. I'm also guessing that the groundwork for implementing a feature like this is already in place due to the ubiquity of addEventListener. To be frank, it seems like a lot of bloat though to avoid a simple comparison. - Less Listener Functions Fired - Instead of every registered listener getting fired on every storage event, only those applicable will be fired. This may mean overall less listeners getting fired, and code that doesn't have to continually check the affected storageArea, leading to potential performance improvements. Actually, assuming only one of the two solutions would exist the same amount of events would fire. A change to localStorage causes an event to be dispatched and likewise a change to sessionStorage causes an event to be dispatched. Having said that, with your solutions more events will fire since the legacy event will have to be dispatched too. Cons: - This is similar to implementing the full EventTarget Interface on Storage areas. However, the only event of importance on a Storage area is storage not click or hover etc. Invalid event types should probably throw an error or something... or maybe this is more in the scope of DOM Events. That is still quite a bit of complexity for little benefit. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Storage Events for a Specific Storage Area
Seems like a reasonable idea. I don't know if it's been brought up before.
My guess is that Ian will say this should be re-examined for HTML6, though.
J
On Fri, Jun 19, 2009 at 9:07 PM, Joseph Pecoraro joepec...@gmail.comwrote:
It sounds like there wasn't any discussion on this. I recently heard talk
of other potential Storage areas [2]. That would make this idea even more
appealing to me. Does this sound like something worth adding? Any
comments?
[2]:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020485.html
On Jun 17, 2009, at 1: 44PM, Joseph Pecoraro wrote:
The storage event [1] fires for both sessionStorage and localStorage.
To me, this means if you only want to interact with localStorage you will
have to manually ensure that it is the storage area being modified:
window.addEventListener('storage', function(e) {
if ( e.storageArea === localStorage ) {
// ...
}
}
Was there any discussion about creating events specific to the storage
object, or should that already be possible? I've been playing around with
WebKit's Storage implementation, and the following (understandably) is not
possible:
localStorage.addEventListener
undefined
Is there any way to listen to events for a single specific storage area or
is the previously mentioned approach preferred?
Cheers,
Joe
[1]: http://dev.w3.org/html5/webstorage/#the-storage-event
Re: [whatwg] Storage Events for a Specific Storage Area
Seems like a reasonable idea. I don't know if it's been brought up before. My guess is that Ian will say this should be re-examined for HTML6, though. Very cool. Let me know if I can help at all to push this idea forward. - Joe
Re: [whatwg] Storage Events for a Specific Storage Area
I'd find these events useful and consistent too All the more when you want to listen events on storage happening very occasionally without the charge of listening other storage events happening very often... You might have some significant performance differences -Message d'origine- De : whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] De la part de Joseph Pecoraro Envoyé : lundi 22 juin 2009 18:56 À : Jeremy Orlow Cc : whatwg@lists.whatwg.org Objet : Re: [whatwg] Storage Events for a Specific Storage Area Seems like a reasonable idea. I don't know if it's been brought up before. My guess is that Ian will say this should be re-examined for HTML6, though. Very cool. Let me know if I can help at all to push this idea forward. - Joe
Re: [whatwg] Storage Events for a Specific Storage Area
It sounds like there wasn't any discussion on this. I recently heard
talk of other potential Storage areas [2]. That would make this idea
even more appealing to me. Does this sound like something worth
adding? Any comments?
[2]: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020485.html
On Jun 17, 2009, at 1: 44PM, Joseph Pecoraro wrote:
The storage event [1] fires for both sessionStorage and
localStorage. To me, this means if you only want to interact with
localStorage you will have to manually ensure that it is the storage
area being modified:
window.addEventListener('storage', function(e) {
if ( e.storageArea === localStorage ) {
// ...
}
}
Was there any discussion about creating events specific to the
storage object, or should that already be possible? I've been
playing around with WebKit's Storage implementation, and the
following (understandably) is not possible:
localStorage.addEventListener
undefined
Is there any way to listen to events for a single specific storage
area or is the previously mentioned approach preferred?
Cheers,
Joe
[1]: http://dev.w3.org/html5/webstorage/#the-storage-event
[whatwg] Storage Events for a Specific Storage Area
The storage event [1] fires for both sessionStorage and
localStorage. To me, this means if you only want to interact with
localStorage you will have to manually ensure that it is the storage
area being modified:
window.addEventListener('storage', function(e) {
if ( e.storageArea === localStorage ) {
// ...
}
}
Was there any discussion about creating events specific to the storage
object, or should that already be possible? I've been playing around
with WebKit's Storage implementation, and the following
(understandably) is not possible:
localStorage.addEventListener
undefined
Is there any way to listen to events for a single specific storage
area or is the previously mentioned approach preferred?
Cheers,
Joe
[1]: http://dev.w3.org/html5/webstorage/#the-storage-event
