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.
Related
Hello I'm using neodynamic weblientprint to print directly from browser. There's a part that includes a script that detects if the client utility is installed, after which its retrives the printers installed on the system.
However I intermittently get this error when the script runs - Unable to launch 'webclientprintvi: -getPrinters: because a user gesture is required.
I get this error on some client system browsers, while some client systems browsers never show this error. Is there a setting that needs to be configured on the browser. Browsers tests are chrome and edge
Thanks.
I discovered that if you are using the WCPP detection feature, then calling jsWebClientPrint.getPrinters() will produce the "...because a user gesture is required" console error. I had a page that called that method w/o the detection and it worked w/o complaining.
I didn't dive any deeper than that as to determining why the extra embedding detection causes this to happen. I just re-worked the page, calling the method instead on a Refresh button click; which, of course Chrome is then happen with.
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.
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.
Using the Worklight v5.0.6 code sample/tutorial "Integrating server-generated pages in hybrid applications" (http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v506/WebViewOverlay.zip) allows for the web content to be integrated. The code sample works fine and web content integrated correctly.
However, when I set connectOnStartup to true in the apps//common/js/initOptions.js file, the tabs and web content from the WebViewOverlay fail to load.
I see in the wlclient.js (apps//android/native/assets/www/default/wlclient/js/wlclient.js) that there is a check that if doConnectionOnStartup is true, then call WL.Utils.wlCheckReachability(), else call finalizeInit()
It appears that the WebViewOverlay and the tabs are created by the finalizeInit() being called, but if connectOnStartup is set true, then finalizeInit is not called.
How can I get both the WebViewOverlay to work and the connectOnStartup to work together?
This is, most probably, caused by connection failure. wlCommonInit function will be invoked only after successful connection, in case connection fails it will never be invoked. First of all - check your connectivity from a mobile handset to WL server. Second, you can either manually use WL.Client.connect() after tabbar was initialized (like Carlos suggested) or specify onConnectionFailure callback in your initOptions.
I provided what I did above in the comments - but it turned out that the dialog box to indicate an update was available was not showing up, and instead the error message "WL.SimpleDialog.show() error in invoking callback." was seen in the log messages of logcat. This log message is coming from worklight.js (apps//android/native/assets/www/default/wlclient/js/worklight.js) on line 820. Just FYI, I did change the worklight.js code to print out err, and it said "No class found". I didn't take the troubleshooting any further at that point
So the app was contacting the WL Server correctly, but the dialog to indicate an update was available was not appearing.
To fix, I simply created a new hybrid app and brought over the necessary code to get the WebViewOverlay to work
This is a bit of a strange bug that I haven't seen before. When loading the login page for a webapp I'm working on in Safari (Mac OS 10.8.2), the entire browser crashes and quits, with the message "safari web content quit unexpectedly". I don't think I've ever seen a site actually crash a browser before, outside of an infinite loop in javascript or something (and really, it doesn't seem like it should be possible). Is there any Apache header or something that is known to crash Safari? Any help pointing me in the right direction would be appreciated.
What I've Done:
Removed all meta tags and it still crashed.
It is getting the SSL certificate before it crashes, because I got the security warning (certificate doesn't match the url, since I'm testing locally)
It's crashing almost immediately, so I doubt that there's any javascript that's causing it
Use the process of elimination. Remove some code, test app. If it doesn't work, continue removing code until you find the cause.
In case anyone ever happens to stumble across this question, the problem ended up being using CSS3 transitions in conjunction with calc() values. Apparently having them together causes Safari to crash (before the transition is even triggered, I might add). I solved it by doing some simple browser detection to add a class to the body when the browser was anything but Safari, and only do the transitions related to calc() values on elements inside that class.