Browser's autoplay blocking prevents playing video/audio of participants that were already in the room

[ancorgs]

Sometimes you join a room in which there were already some participants, you don't get any audio/video from them. So far, the most common workaround has been ignoring/unignoring them.

The real root of the problem is that browsers are blocking the reproduction of the video and the audio. The connection is correctly established and the information is being received. It's simply not played due to a feature of the browsers designed to protect the users. See https://developer.mozilla.org/en-US/docs/Web/Media/Autoplay_guide

Now that we know this is an UI problem and not a WebRTC one, we need to design a good solution, that very likely will imply forcing some user interaction previous to start playing the streams.

[ancorgs]

@teclator this is the problem you (we) have been experiencing. At least now we know why it happens.

[dgdavid]

Nice catch @ancorgs!

Thanks!

[mvidner]

As a user, I would be fine to encounter a popup, saying

Chat room 'Testing' entered.
Video will start when you close this.
(This popup is enforced by browsers protecting you from unwanted audio/video autoplay)
[OK]

(assuming that it actually solves the prolem)

[ancorgs]

What most applications do is to have a previous test screen/popup. So you can see yourself and test the audio and then click "join" to actually join. Turns out that's indeed a trick to workaround this problem. :-)

[ancorgs]

In my recent tests I see this in the console of my firefox:
Autoplay is only allowed when approved by the user, the site is activated by the user, or media is muted.

So maybe starting with disabled audio/video by default could be enough. Maybe only the first time you access a given room. I don't know, I'm just speculating.

[ancorgs]

I have not experienced this with version 0.6.0. Since we refactored the UI, it's possible we are not longer affected. But we really need to verify that.