This isn't abuse, it's what the storage event was specifically made for. Facebook, Google, etc. have been using this event to update common state information between tabs for quite a while.
Yup. We use it in our Backbone.js app to allow users to open links in new tabs and for changes in those tabs to propagate back too.
For me it is awesome to use PushState and LocalStorage in a client side app and all the while the user thinks they are using a "traditional" server side app.
Don't be disappointed! This is slick, and easy to understand. I don't really want to digest the javascript Facebook is using to learn a new tool/concept.
The primary caveat with this approach is race conditions due to lack of locking. Note the "Issues" section in http://www.w3.org/TR/webstorage/ which says:
"""
The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable. Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after. If reviewers have any suggestions, they are urged to send them to the addresses given in the previous section.
More details regarding this issue are available in these e-mails (as well as numerous others):
It depends on what you mean by atomic. Please refer to http://www.chromium.org/developers/design-documents/indexedd... where Chromium devs state:
"""
LocalStorage is inherently racy or a parallelism disaster, depending on whether or not you're willing to implement the "storage mutex" described in the spec. Chromium has decided not to implement it. WebKit itself is single thread/process (i.e. no parallelism period).
"""
Note that the way Chromium implements localStorage, it uses a disk backing store of sqlite, a caching layer (a std::map) in the browser process, and a caching layer (also a std::map) in the renderer processes (where WebKit runs, and may handle 1-X tabs per process). Changes are propagated via IPC, but as the API does not provide any locking guarantees beyond the optional storage mutex, which Chromium does not implement, there are obviously race conditions.
This probably explains the issues the author of that post encountered with Chrome.
This method may allow message passing between tabs, and windows, but it does not do so between iFrames. Two iFrames on the tab will not trigger storage events on each other.
As far as I can tell this does not work cross protocol from http to https. One of the thing I use postMessage for the most is messaging between those two protocols.
I was attempting to do something similar, but needed to support IE7 which doesn't support localStorage. You could probably rely on userData as a fallback though.
Yes, there are potential security issues with this, but as with anything in the browser you need to think through where your secrets are held. A similar issue comes with setting an expiry time of a few hours on a resource to let the browser cache it, so it's something web developers have been battling against for years.
I was intending this to be a "nice to have if it works", rather than essential to my app. But do people really use multiple tabs on a single site that much on mobile devices?
