Re: [webstorage] inactive documents

On Mon, Apr 27, 2009 at 6:30 AM, Anne van Kesteren <annevk@opera.com> wrote:
> Consider having two windows A and B where the session history of A consists
> of A1 and in B it consists of B1 and B2. A1 and B2 are both fully active.
> A1, B1, and B2 are all same-origin. Now everytime the Storage object of A1
> and B2 are updated B1 will get more and more out of sync because it does not
> receive the storage events. That seems bad.
>
> One solution would be to queue storage events for B1 to be dispatched when
> it becomes active again but if a lot of storage events are dispatched it
> could take a while before the page is functional again when you go back to
> it. In naive implementations of such a strategy the message queue could also
> be exhausted.
>
> Another solution would be to introduce an event for when a document changes
> from inactive to active so the document can reinitialize itself.

We do have an event like that in firefox called 'pageshow'. However I
don't think we can expect authors to remember not only to listen to
'storage' events, but also remember to "flush" on 'pageshow' events.
It basically seems to me that a design where anyone listening to just
'storage' but not 'pageshow' has a bug, is a bad design.

I can think of two other solutions:

Either we simply ask implementations to not cache windows with
'storage' listeners. IIRC we do something similar with pages that have
listeners for 'beforeclose' listeners. Alternatively, implementations
can queue up 'storage' events until the implementation thinks that so
many events have been queued up that firing them all would lead to bad
UA, at which point the implementation can remove the window from the
cache.

Alternatively, we can make it such that the 'storage' event can be
fired with no indication of which value changed, in which case the
page should assume multiple changes have been made. Though this
carries much of the same risk as relying on a 'pageshow' event since
developers are unlikely to expect it.

/ Jonas

Received on Monday, 27 April 2009 18:44:29 UTC