Currently WebRTC fails on Brave browser with "Autoplay was blocked on this page" error.
This error is not particularly visible:
You can test it with Brave browser where any WebRTC is enabled, e.g. https://test.webrtc.org/.
My app users are reporting this as a bug – since their experience is that the video is just not loading.
What is the proper way to handle this?
https://webrtchacks.com/autoplay-restrictions-and-webrtc/ has quite some (still valid) suggestions. Checking the audiocontexts state as suggested here (linked from a comment) is probably the way to go.
It is rather surprising that brave does this, chrome does allow autoplay when getUserMedia is active.
Related
I'm working on an html application that uses getUserMedia. It works great so far but there is one little problem:
The web application is also being called from local file system. That means file://.
Ok, WebRTC is unavailable in this case. When the Browser tries to call
navigator.getUserMedia({video: true, audio: false}, function(localMediaStream) {...}, function(error) {alert("blabla webrtc unavailable";)});
it should run into an error and call the error callback.
In case of file://, none of these two callbacks will be ever called.
In another case, the web application is running over regular http://, a warning is given, that the WebRTC feature is unavailable in insecure environments, but here the error callback is working as expected.
I need the error callback to tell the user, that WebRTC is unavailable.
What is wrong here?
(It is used for an unimportant feature. And only getUserMedia() is used, not the entire WebRTC-Workflow. But it is ugly, if it run into a blank screen)
And no, there is no waiting popup which ask the user for permission :-)
The problem is Chrome only. Probably a Browser bug?
Thanks.
Silently failing for file:// is documented Chrome behaviour, see here. If you can control Chrome, the allow-file-access-from-files flag enables getUserMedia from file urls.
I use the Google Chrome remote debugging protocol to get benchmarking information of the page loading process with Google Chrome. I would like to switch to Opera which should offer the same functionality now that it runs on Chromium.
I started Opera with the cli parameters "--remote-debugging-port=9222 --enable-benchmarking --enable-net-benchmarking" similar to starting Google Chrome. I discovered that benchmarking seams not to be started in Opera - the chrome.benchmarking object is not visible to JavaScript.
I didn't find any documentation on the cli parameters for Opera, neither how to work with the remote debugging protocol in Opera.
Does anybody know how benchmarking can be enabled and/or the remote debugging protocol works in Opera?
Maybe you don't need this anymore, but I did today.
For some reason (maybe it's by design, but I didn't bother to check), you can't really start two separate instances of Chropera. Therefore, you first have to exit opera (from the menu to save your session).
Then, find your installation directory, and start Opera with the params:
C:\PROGRA~2\OperaNew\31.0.1889.174>opera --remote-debugging-port=9222 "http://www.opera.com"
(Maybe you can use launcher.exe, but I didn't bother checking)
Then, using another browser, visit http://localhost:9222. Maybe you can use the same one, but again, I didn't bother checking.
Now it's just the same as the Chrom(e|ium) protocol.
Hope that helps somebody.
I have safari 5.1.7 , but under the Debug menu I can not find any option to stop the auto-refresh. I try un-checking the "Use multi-process tabs", but it did not solve the auto-refresh problem. any idea about disabling auto-refresh inside safari 5.1.7 ?
Today I inadvertently discovered a way to stop this annoying behavior, even though it does not qualify as a real fix, it is a method of suppressing the behavior by taking a simple action every time prior to switching out from Safari or another browser. Not ideal, but it does give you control (finally) of the browser such that the behavior is suppressed. The link to the answer is here:
https://discussions.apple.com/message/25254749#25254749
My WebRTC app works fine when I connect two of the same browsers, but when I try a combination neither respond to each others signaling messages. Something probably worth mentioning is that I have not implemented TURN, however I don't see why that should make a difference so I'm not going to change that unless I'm fairly certain it will.
I don't have much of a clue where the error lies, so I will just add code on request for the sake of readability.
Make sure you enable DTLS-SRTP (Firefox only supports DTLS-SRTP) by passing the following to the PeerConnection constructor:
{ 'optional': [{'DtlsSrtpKeyAgreement': 'true'}]}
See this page for more details.
You have not really described what goes wrong with the signaling. No error messages and so on.
But based on the fact that you only see the fault when using two different web browsers I would recommend using Adapter.js that have been somewhat promoted from webRTC.
Link to webRTC demo that shows on the interoperability using Adapter.js(page also contains a link to Adapter.js):http://www.webrtc.org/demo
Direct link to
adapter.js
Try to turn off your firewalls to check if it fixes the problem.
In my case (Windown 7), default windows firewall didn't allow UDP for Private Inbound Connection Setting and Firefox + Chrome p2p connection just didn't work.
Hope it helps.
When I visit the Spotify Play Button demo page (https://developer.spotify.com/technologies/spotify-play-button/) in Opera 11.62, clicking on the Play Button gives me the (mostly-expected) popup:
The application "Spotify" must be launched to open the link:
spotify:
Do you want to proceed?
If I click yes, the Spotify app then launches (if not already running) and gets focus, but does not play anything. I suspect the link is getting broken by Opera somehow (notice that it has the spotify: protocol name but nothing after that). The Play Button on my own site produces the same behavior. Works fine in Firefox on the same machine.
Has anyone else experienced this?
Yes, sadly, that's the case. There's a similar issue in Opera's bug tracker.
I think your particular issue could be related to Opera's lack of support for cross-origin resource sharing (CORS). CORS support is coming is available in Opera Next, but not Opera 11.62. If it doesn't work in Next, I encourage you to file a bug report.