wingify / across-tabs

Easy communication between cross-origin browser tabs. Simplified "CORS"ing!

Home Page:https://engineering.wingify.com/across-tabs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Shared web workers

rugk opened this issue · comments

commented

Skimming the Readme I could not find any "how it works" section, which explains how it basically works.

In case it does not already use shared web workers, I would suggest this a an alternative for modern browsers.

Hey @rugk, this library doesn't use Shared Web Workers.

This library uses postMessage API to communicate between browser tabs. It also uses SessionStorage to persist the Child's Identity as long as the Child's session lasts(this helps in maintaining the independent ability of the Child tab to work even in case the opener tab i.e. Parent gets closed).
Also, postMessage helps in overcoming the Cross-Origin communication restrictions. The API support is good enough to support all major browsers http://caniuse.com/#search=postmessage and supports more browser versions than shared web-worker.

Please refer https://github.com/wingify/across-tabs#flow-diagram for the detailed explanation of "how it works" from the initial state(clicking the link button) to the state when the communication channel has been setup and messages are ready to be exchanged.

Let me know if you still have doubts regarding the working.

commented

Okay, so do you see any advantage in using shared web workers. I mean that's the "latest fashion". 😉

@rugk The main purpose of this library is to allow Cross-Origin communication between tabs. Going through the Shared Web Worker API docs, it states that:
If SharedWorker can be accessed from several browsing contexts, all those browsing contexts must share the exact same origin (same protocol, host, and port).
Also,

In Firefox, shared workers cannot be shared between private (i.e. browsing in a private window) and non-private documents

So, SWW can not be used with Cross-Origin sites. For eg,

Lets assume http://example.com opens up a tab(http://another.com) which by definition, is not on the same origin. In this scenario, another.com wouldn't be able to communicate with the SWW and hence can not setup a channel to communicate back with its opener tab i.e. example.com.

Whereas AcrossTabs uses PostMessage API which works across Cross-Origin sites. SWW too uses postMessage API internally to communicate but don't allow Cross-Origin communication for security reasons.

So, in a nutshell,

  1. SWW doesn't support Cross-Origin, but postMessage API does So, AcrossTabs uses postMessage API to facilitate Cross-Origin communication.
  2. Using SWW, if a message needs to be passed on from the opener tab to the opened tab, first the opener tab has to send a message to the SWW's port via postMessage and then SWW will pass on that message to the opened tab. Same goes vice-versa. Whereas using postMessage directly, we can save one trip and send messages tab-to-tab.
  3. SWW uses a separate thread and there's NO window and document objects available.
  4. As mentioned earlier, SWW doesn't have support for many browser versions.

IMO, I don't think there's any advantage in using SWW over direct postMessage API, instead, there are drawbacks.

Closing this ticket. Let me know for any more concerns.