don't skip cross-window syncing under normal circumstances

[akatov]

I assume the code before was a bug. It used to skip cross-window syncing under normal operation, and would actually only sync in testing mode when the document was hidden.

[fsmanuel]

@akatov thanks for the PR. I'll review it later.
There was a discussion about the behavior: #47

Not sure if it's a bug. I have to read the discussion above...

[fsmanuel]

@akatov can you rebase against master? I fixed deprecations in the tests. Now the tests should pass.

[akatov]

OK, having read #47 I now see the reason for the change you made that I thought was an obvious bug. I made this pull-request without this context.
Now, the real problem is document.hidden. We can't simply assume that we should only update values in non-focused tabs, just like we can't simply assume that changes will be fired only from focused tabs (well, visible tabs really, since document.hidden is false as long as a tab is focused in a window, even if the window isn't focused), as this only reflects a limited amount of use cases.
For instance, my use case is the following: I have two windows open, where one (the main window) receives events from the server and changes data (so it doesn't have to be focused), and the other one (the popout window) just needs to receive the data from the main window.
I'd say that having sync'ing functionality in all use cases is more important than trying to prevent double updates in a runloop (there are other ways to guard against this).
Maybe we should try and see whether we can solve the live-lock issue discussed in #47 using Ember.run.once in StorageMixin#_save?

[akatov]

oh, and this PR is inappropriate in any case as I have now pointed out that document.hidden simply shouldn't matter in making a decision whether to react to localStorage events or not.

[fsmanuel]

@akatov do you have an IE 11 at hand to test Ember.run.once?

[akatov]

yes, Ember.run.once does a good job on MSIE version 11.0.9600.16428IS. With the new code in the PR you can update a property twice and it will only end up getting updated once in the other tabs / windows, so should solve the problems talked about in #47 without ever referring to document.hidden.
I did discover some interesting behaviour with the tests though - looks like getting a property backed by storage has to be in a runloop when doing it for the first time. Also, some tests now fail, probably also linked to this behaviour, so I would greatly appreciate some comments about how to work out these discrepancies.

[akatov]

I rebased and forced pushed some updates to tests (more use of the run-loop when getting storage backed properties). For some reason ember-try fails on the ember-beta scenario on travis, but it runs fine locally when using PhantomJS 2.1 (rather than travis's 2.0).

[fsmanuel]

@akatov I think I found the bug. I have to test it but I think we should use set(this, 'content', JSON.parse(event.newValue));. this.set calls the mixin implementation that triggers a new save... loop...