Share connection across multiple tabs

[leewang0]

It might be possible to share one signalR connection across several browser tabs by abusing local storage. CallR could, (though probably shouldn't by default), store state in browser's local storage on whether or not it has an open SignalR connection to a particular hub. If it does, then when another browser tab tries to connect to it, intercept the connect call and instead pass messages to the tab with the connection via local storage. This assumes that the other browser tabs will periodically check local storage to see if the one connection has returned the results of their call, effectively long-polling it. Since there's no network latency involved in checking local storage, though, this should be an ok way to do it as long as a clever way to store signalR requests and tab-origins can be put in local storage.

[tejacques]

I think this is a neat idea, but there are a ton of edge cases / tricky things to work out, here are four off the top of my head.

• Checking that the tab with the connection is still active -- who picks it up if it isn't?
• Sending results to the other tabs (both broadcasts and individual responses)
• Concurrency: Multiple tabs accessing the same local storage data. Seems prone to errors, but maybe this is handled gracefully by local storage itself, but I'm not familiar enough with it.
• Some browsers may pause JS execution (like mobile browsers) on all but the viewed tab. This would need to be handled gracefully

I think these could all be addressed but it adds a huge amount of complexity. The benefit of adding this feature is that no more than one connection per browser would be made to signalR, which is great, but probably not the most common use case.

I'll consider this as a future feature but there are other easier ways of getting past the n-connection limit, like having multiple subdomains, etc.

[tejacques]

After doing some more research, it does look like atomic mutexes can be utilized to get past localstorage concurrency, and StackOverflow actually uses this trick in their chat:

I think it could work like this:

• You can set events for items in localStorage. This allows you to broadcast changes to tabs.
• The master tab will maintain a last updated/checked time in local storage. If this falls too far behind, then the next tab that checks localStorage will promote itself to master.
• Using the unload JS event in supported browsers, we can check if that tab was the master and set the last updated/checked time to 0.
• For Concurrency, use something like lockableStorage for thread-safe localstorage access

Other resources:

• Inter Tab communication using local storage
• Same as above, in a working example: http://www.nmjenkins.com/intertab.html