Why did Safari drop support for SharedWorker?
And are there any working polyfills using, for example, localStorage and StorageEvent as a communication port? (Yes, the shim would have to detect and recreate the master Worker)
Directly from one of the WebKit Engineers:
The implementation of Shared Web Workers was imposing undesirable
constraints on the engine. It never gained any adoption.
Source here
I can't find any polyfills for SharedWorker.
It seems that one can be created by implementing a StorageEvent based communication port across workers. The downside being that StorageEvents are not portable for WebWorkers, and you have to maintain state across each browser tab and know when to flick on/off each master worker.
From my understanding the answers here are correct, but it's also due to the lack of SharedWorker adoption by web developers (a chicken and egg type situation).
If you're in need of a polyfill, you can use the one I created. I couldn't find one for one of my projects, so I created this one, https://sharedworker.okikio.dev/.
Note: it doesn't handle cross tab communication, but you can use the CacheStorage API together with a ServiceWorker and MessageChannel or use IndexedDB and ServiceWorker (from #jakearchibald on Twitter) to create a similar effect
Also: I should mention that Safari is working on supporting the BroadcastChannel API, which would cover the cross tab communication aspect, it's currently available in the Webkit Technology Preview
Since safari default's behaviour on cookies is preventing third-party cookies on tracking.
If safari allows us to use SharedWorker, developer(google or tracking company) can use it to access identify between different window tab.
That's the reason why safari drop the SharedWorker, interestingly, it support WebWorker but not SharedWorker.
It's my guess, not the official reason.
Related
How does one share a single WebSocket connection across multiple browser tabs?
I'm aware of multiple questions/posts suggesting SharedWorker. However, it is not a viable solution due to the poor adoption of SharedWorker (only 35% globally according to Can I use at the time of writing), not to mention it has been dropped in Safari.
I have implemented a working version using SerivceWorker, which has some SharedWorker's capability, to share a single connection across tabs. Unfortunately during testing I realized that ServiceWorker can be killed/stopped by the browser, especially when the devtool is not opened. I'm also aware of some workaround to prevent this behaviour, such as pinging the ServiceWorker periodically. I would like to ask whether there is a proper way to handle this.
Unfortunately is not a straightforward task. But because many browsers are limiting the number of connections to the same origin it is an issue I faced a few times.
Sharing a WebSocket
Assuming you are forced to share the connection and other options are not feasible, these are the possibilities:
SharedWorker (33.17% support). Allows you to share the connection as you already discovered.
BroadcastChannel (91.23% support). Allows you to communicate between tabs.
SessionStorage (97.25%). Allows you to communicate between tabs. This is a bit of a hack see but worked well for me.
The trick for 2 and 3 is that you will have only one tab holding the WS connection and sharing its usage with the other tabs through the communication channel. The trickiest part is when the "main" tab is closed; you will need to elect another tab to open the connection.
Please note that both 2 and 3 are subject to buffering delays and additional delays during the change of the "main" tab. SharedWorker also has its pitfalls. Thus none of the solutions are suitable for high-speed real-time applications (like a game). If you need a real-time solution or just one that is easier to implement go for the following option:
Unsollecitated option
If you just need to work around the connection limitation, this is a cheat that works flawlessly: create a domain like *.wss.example.com that points to the same server and then trick the browser by randomly generating the domain on each tab (something like 3af893.wss.example.com, a6a589.wss.example.com, ...). With this pattern, you can make unlimited connections. Just remember to setup solid CORS policies as this pattern exposes you to huge amounts of malicious traffic otherwise.
Despite implementing many of the above mentioned solutions, I ended using this one in production as it prooved to be more stable and reliable. This solution also works for Server Side Events (SSE).
Edit 1
Many of the mentioned options are discussed here Sharing websocket across browser tabs? as mentioned by Eskandar
I've got a client that has some legacy sites on their intranet that can only run in Internet Explorer. They have IE on all their PCs, although other browsers are used within the company. They also have no funding to update the sites, and have used workarounds like browser-specific desktop shortcuts and IE Tab to access the sites. However, they were asking if there was some way to create website links that would force the pages to launch in Internet Explorer only, no matter what browser was being used originally. My immediate response was 'no', and digging around the internet has confirmed this, but I'd ideally like to tell them WHY it isn't possible. Can anyone shed some light on this?
Allowing websites to access PC data and invoke programs would be a major security risk.
The HTML standards define how web browsers should behave when presented with standard markup. Executing a program on your computer (in this case, Internet Explorer) is clearly not a function of a web browser and the means of doing so is thus not defined via HTML.
You may be able to accomplish what you're looking for by writing/installing some add-ins or plug-ins to Chrome/Firefox, augmenting the standard functionality of those web browsers. Just note that if you go that route, you'd be potentially creating a security vulnerability.
I'm not being able to create a RTC dataChannel between Chrome and Firefox. I had success creating video and audio streams between the two browsers, but not the dataChannel.
If the communication is between two Firefox browsers or two Chrome browser, it works. Is it possible to create a dataChannel between those two?
Thanks.
Yes, it possible to create data channels between Chrome and Firefox. There's a bit of custom code required to achieve connectivity but it's not too bad.
I recommend using a module that smooths over the differences and simplifies the WebRTC API. I wrote simple-peer for this purpose. You can take a look at index.js to see where there is custom logic to handle Chrome or Firefox quirks.
Another popular solution is adapter.js (created by Google), which attempts to smooth out the differences between browsers without making the API easier to user.
The title basically says it all. I'm aware this can't be done using traditional means. I'm not aware of any way to do it using Web Sockets, though I've never built anything more than toy apps with them.
It is fine if the solution is browser-specific (even on the client-side; i.e. peer-to-peer communication would also be awesome). For instance, is there any way to accomplish this using Chrome's NaCl?
Furthermore, if this isn't possible now, is there any fleshed-out specification for how it will work in the future? For instance, Chromium-based browsers are experimenting with a "P2P Javascript API" which appears to be currently entirely undocumented.
Here's the HTML5 spec on it:
http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#peer-to-peer-connections, though its status is unclear.
Sorry if this question is a bit haphazard; I'm basically interested in the current status of all in-browser APIs that could be used for p2p communication.
Edit: I'm not interested in Flash p2p. I'm aware it can be done, and is definitely a solution to current p2p problems, however I'm interested in new technology.
Update May 2012: For those still looking at this, the peerconnection API is slowly making its way into browsers. It is now experimentally in Chrome, along with the rest of the WebRTC API. You can check out the documentation and spec here.
There's Opera Unite but I'm not aware of any cross-browser standardization effort based on that. I think by default it proxies through Opera's servers for DNS, but you can set it up for direct connections.
Chrome has bundled a "native" flashblock for a while, as has the android browser. swfobject reports that the flash player is available, even if the block is enabled for all sites. All I want to do is detect that a user is using native flashblock, and provide some messaging. Certain services, like the Facebook JS SDK, do not work without flash enabled for cross-domain communication, and do not provide methods of detecting failure. I know how to detect an extension/plugin like the original flashblock, but the native version does not appear in the navigator.plugins list.
Is there a way to detect if a user is running with a native flashblock enabled?
Unfortunately, there's no programatic interface to the plugin-loading system in Chrome.
The best you can do is to load a flash object, and poll it via some well-defined method (GetVariable("$version") is the canonical example) to determine success. In the case you're concerned with, flash will show up in navigator.plugins, but won't successfully load your test plugin. It's really not a bad idea to do this sort of check anyway, as there are a number of reasons that flash might not load, above and beyond flash-blocking (native or otherwise).