We Keep Coding

Audiocontext was not allowed to start in lib-jitsi-meet

I'm developing a video chat application using lib-jitsi-meet. It's all working fine in Firefox, but when it comes to Chrome, it throws the following error in the console.
lib-jitsi-meet.min.js:1 The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page.
The participant can't use the microphone in the Chrome browser because of this error. I know this is related to the changes in Chrome autoplay policies. I could've done something if I'm using the pure web audio API, however, I couldn't understand what should I do to avoid this in lib-jitsi-meet.
I searched for this error in Jitsi community forums and many other places but didn't find any helpful answer to circumvent this.
How can I overcome this issue so that video chat participants from the Chrome browser can use their microphones and hear what others are saying? Thank you for all the helpful suggestions.

This problem occurs with Jitsi Meet NPM package. Upon importing it to my React app as
import JitsiMeetJS from 'lib-jitsi-meet-dist'
it automatically creates a new AudioContext object. Since that is not allowed in Chrome due to its autoplay policies, I cannot either access the microphone or listen to other participants. I could've resumed the created AudioContext and go on, but there was no way to do that in the library.
As a solution, I added the Jitsi Meet library as a script in the index.html of my React app and used the JitsiMeetJS object in the app as window.JitsiMeetJS.
<script src="https://meet.jit.si/libs/lib-jitsi-meet.min.js"></script>
With that approach, there was still an AudioContext object initialized, but it's related to something called collecting local stats, not Jitsi Meet core functionality. Therefore, I could ignore it and move on.

localmedia access restricted until user interacts with the page in firefox

I have given allow permission for Microphone in my domain. We are using our domain in multiple tabs. I am able to acquire local media (Microphone) when I am accessing in the same tab. But I am not able to acquire local media for WebRTC in the other tab(same domain) without visiting the tab .Only after visiting the tab localmedia access is acquired.
Is it intentionally done for Security & Privacy? . Is there any way to solve my problem ?
Reason: To restrict resources being used for WebRTC session. We are keeping WebRTC session in single tab for our domain and using only that resource for all the tabs to make calls.
Tried setting microphone-allow as iframe attribute . But it didnt solve the problem . It is working fine in GoogleChrome browser though. If I open a new tab(T1) and initiate webrtc in it and make webrtc call from another tab (T2)without ever visiting the tab T1 , call is connected in chrome but not in firefox unless i visit T1 .
Note : It is not asking permission for allowing microphone in the domain , it acquires it automatically . Just that it acquires only after i visit the tab .I have given microphone access permission to my domain already.

Is it intentionally done for Security & Privacy?
Yes, this is intentional to prevent background tabs from turning on the camera or mic willy nilly, to spy on users. Because that's creepy. I believe Safari works the same way.
The getUsermedia specification recently made this a requirement:
Step 6.1. "The User Agent MUST wait to proceed to the next step until the current settings object's responsible document is fully active and has focus."*
So I would expect Chrome to follow suit soon.
Is there any way to solve my problem ?
That would very much defeat the assurance.
Users can rest assured that only the currently focused tab can turn on the camera or microphone.
If I open a new tab(T1) and initiate webrtc in it and make webrtc call from another tab (T2)without ever visiting the tab T1 , call is connected in chrome but not in firefox unless i visit T1.
That's an RTCPeerConnection connection problem, which is separate from getUserMedia.
The workaround is to not block connection establishment on mic access.
There's no reason you can't connect first and add the mic later.
Or get mic ahead of time, and connect later. Basically, the two actions don't need to coincide or block each other.

Can I make a socket connection through Javascript

What I want to do
Make a simple socket connection to a server on the browser. I want to not send any header information with the socket connection.
The Problem
It looks like I am unable to make a socket connection with javascript that does not send header data (Is there a way to do a tcp connection to an IP with javascript?).
I thought maybe I could make a connection with a chrome extension, however it looks like the socket API is only available for chrome apps (Google Chrome Socket API in extensions).
I am thinking that I might need to make a native application that will make socket connections through requests made by the browser using Native Messaging.
Is there anyway I can achieve this or am I out of luck?

Raw socket connections through the browser are wrapped up in security concerns. Users can be easily manipulated to allow things to run that shouldn't.
TCP and UDP Socket API
W3C Editor's Draft 20 January 2016
is located here.
http://raw-sockets.sysapps.org/
Mozilla's API information here: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/TCPSocket "This API is available on Firefox OS for privileged or certified applications only."
If you work with raw TCP connections. I would suggest
(1) downloading PHP onto the local computer. PHP has a developer web host build in so you can run whatever application you want on PHP using the browser as your GUI.
(2) download node.js.

You are not out of luck you just need to achieve it with the understanding that you are working outside the box for normal browser based scripting created from security concerns, and that means the user/client needs to install something manually.
If you must use chrome browser on the client side, you will need to make an -extension- correction webapp. You can as a developer make one that you can use on your own computers.
https://developer.chrome.com/extensions/getstarted
https://developer.chrome.com/apps/first_app
Load the extension#
Extensions that you download from the Chrome Web
Store are packaged up as .crx files, which is great for distribution,
but not so great for development. Recognizing this, Chrome gives you a
quick way of loading up your working directory for testing. Let's do
that now.
Visit chrome://extensions in your browser (or open up the Chrome menu
by clicking the icon to the far right of the Omnibox: The menu's icon
is three horizontal bars. and select Extensions under the Tools menu
to get to the same place).
Ensure that the Developer mode checkbox in the top right-hand corner
is checked.
Click Load unpacked extension… to pop up a file-selection dialog.
Navigate to the directory in which your extension files live, and
select it.
Alternatively, you can drag and drop the directory where your
extension files live onto chrome://extensions in your browser to load
it.
If the extension is valid, it'll be loaded up and active right away!
If it's invalid, an error message will be displayed at the top of the
page. Correct the error, and try again.
This insures that non developers don't load an extension which does not comply with the normal security concerns.
Communicating between with the script on the web page to the extension.
Can be done with message passing ... https://developer.chrome.com/extensions/messaging
The extension can add content directly to the web page which is available to the script on the web page. If for example the extension replaced the web cam image with a static image when the webcam script reads what it believes is the webcam it gets the static image instead, which explains why I look like an alien from space on the webcam. Although I did not create an extension to do that, I merely modified an existing extension to replace the function that gets the webcam image with a function to get a static image.

You can use SignalR, it is javascript library (JQuery Plugin) and it enables you to open web sockets from the browser to a server. Please check the following links:
https://blog.3d-logic.com/2015/03/29/signalr-on-the-wire-an-informal-description-of-the-signalr-protocol/
http://blog.teamtreehouse.com/an-introduction-to-websockets
https://github.com/SignalR/SignalR

How to get Chrome to stop asking me whether its ok to use the camera?

I am doing some html/js/webrtc work with the webcam. Even though I am hosting files from the web server on my machine (thus 127.0.0.1), Chrome asks me whether its ok to use the camera every time I reload the page.
How can I get it to stop?

Just activate chrome://flags/#allow-insecure-localhost. This will work like https and fix a lot of development problems, including invalid ssl certificates.

use https. Chrome does not persist permissions on http and getUserMedia will stop working there soon (even though possibly not on localhost).
Alternatively, use command line flags like --use-fake-ui-for-media-stream to skip this.

Keep WebSocket alive in Mobile Safari

Is it possible to keep a html 5 web pages WebSocket connection open in Mobile-Safari once the screen is locked?
I want to send my users continuous updates throughout the day and it seems silly that their screens should always have to be unlocked to receive those notifications.
Are there any other options?

I don't think it's possible to keep the connection open while the browser is in the background, or when the screen is locked, the reason being that the app is essentially frozen in memory. Here's a quote from a similar question:
the reason you cant keep a network socket open, is that without your app jumping to the foreground when it receives a connection, it cannot respond to network traffic(because if it is not in the foreground its memory content is frozen).
However, I did find this page on Push Notifications for Websites that shows you 'how to sign up your users to receive notifications even when your site is not running in Safari'.
There are some other options: if you want to send continuous updates, you could write an app and either follow the instructions on Apple's site to keep a socket open permanently, or you could configure the app to implement Push Notifications.
I'm sorry I couldn't find a quick fix, but I hope at least one of these options works for you!

I have found a hacky way to keep WebSocket alive in Mobile Safari.
Basically it's the same solution as for this question.
Create an infinity looping audio file to keep Javascript running:
<audio loop src="http://www.sousound.com/music/healing/healing_01.mp3"></audio>
Note: some user interaction is required to initiate the audio file.
It would be nice if a WebSocket kept the browser alive in the same manner as an audio or video file.
PS this also works on Android.