I'm having serious trouble in getting getUserMedia to work in Firefox 20. What I would need is a simple webcam capture.
I've tried a couple of examples over the web, here's one for example:
http://www.html5rocks.com/en/tutorials/getusermedia/intro/
Is it so that Chrome is actually the only browser supporting the getUserMedia properly today? I've also tried photobooth.js with no luck. Any good solutions around?
Thanks in advance.
Chrome 21+, Firefox 17+ and Opera 12+ actually support getUserMedia (been using it as well). But Chrome and Firefox still prefix them with webkit and moz, respectively, so you need a simple polyfill to patch up the differences.
I read somewhere before that the initial versions of these browsers that supported these features had them disabled by default. You need to enable them first. As far as I have used these browsers, the latest versions have them enabled (FF20 and GC26)
In order to use getUserMedia, it has to be hosted on a web server. An error will be thrown if you try to run the page locally. If you have NodeJS installed, you can run this little NodeJS script to run a portable static file server.
in webkit you hve to prefix webkit and in moz you need prefix moz . you can use adapter.js as polyfil so you can call the same function to work in all web rtc enabled browser . And web rtc still have problem in chrome to moz or moz to chrome Peer connection
you are needed to enable flags in chrome 24 or less . but with chrome 25+ it is flagless
Related
I have a pretty standard geolocation implementation I'm using in JavaScript.
navigator.geolocation.getCurrentPosition(
function (position) {...},
function (error) {....}
);
It is and has been working great on Internet Explorer/Chrome on my main Windows machine, physical Android, IOS on different iPhones...It's not working on my Macbook Pro with HighSierra and latest Safari though.
I downloaded an old version of Safari for Windows, and while I know it's old and deprecated, I figured I could at least see and it doesn't work on that either so I feel like that somewhat means something as far as testing goes.
The error code I'm getting back is POSITION_UNAVAILABLE. Here's where it gets really weird, I got so fed up because it really is on my end inexplicable, I decided to try other websites on Safari that have demo geolocation to test, html5demos.com, w3schools etc. All return same thing on Safari when debugging their code. Same thing with the older version of Safari for all tests on all websites on a completely different machine.
My site is HTTPS, I have confirmed location services are enabled on Safari for the website, I'm prompted for approve/deny location. I've confirmed all location services are active on the MBP system preferences. I have no idea what the heck is the deal, I can't confirm if...it's something...on this machine since it's my only MBP I have access to, but again it works on mobile IOS and every other website I've tried that has a Geolocation demo on the MBP does not as well on my Windows box with the last available version of Windows Safari 5.1.7. I'm using wifi if that matters at all since I've seen a hard connection for whatever reason coming up sometimes as a problem when consulting Google.
Any ideas?
I want to determine use combo or not by the environment support http2 or not. But, I cannot find the method to check if a browser supports http2 or not in browser.
Thank you in advance.
Navigation Timing 2 API provides this information:
performance.getEntriesByType('navigation')[0].nextHopProtocol
The above should return 'h2' on a page that got fetched using HTTP 2
A note on limited compatibility of nextHopProtocol:
Navigation Timing Level 2 API is currently in working draft status so support for the nextHopProtocol (which is being introduced with Level 2 API) will be limited (unsure of exact browsers supporting it since caniuse currently doesn't include Navigation Timing Level 2 API).
According to HTTP/2 Frequently Asked Questions HTTP/2 and caniuse is supported at IE11, Edge14+, Firefox 52+, Chrome 49+, Safari 10.1+, Opera 45+, iOS Safari 9.3+, Android Browser 56, and Chrome for Android 59.
Can I use HTTP/2 now?
In browsers, HTTP/2 is supported by the most current releases of Edge,
Safari, Firefox and Chrome. Other browsers based upon Blink will also
support HTTP/2 (e.g., Opera and Yandex Browser). See the caniuse
for more details.
The easiest solution could be to find the User Browser version and user agent.
Sample javascript code to find User Agent :
function myFunction() {
var x = "User-agent header sent: " + navigator.userAgent;
document.getElementById("demo").innerHTML = x;
}
We can make a Map with browser name and version and after splitting user agent we can know if the Browser version support or not.
With the server side language like Java, it's easy to get Request agent which can tell HTTP version, but with Javascript without Ajax, it's bit more code needs to write.
To find a number of Browser and which version of browser follows HTTP2 please refer to :
https://www.smashingmagazine.com/wp-content/uploads/2016/01/01-caniuse-spdy-opt.png
I could not find another way.
I think there is only way to check the browser and operating system by looking at the following items.
https://en.wikipedia.org/wiki/HTTP/2
http://caniuse.com/#search=http2
I have an NPAPI plugin which works fine for Firefox, Chrome and Opera (Windows & Linux both). Now, since the support for NPAPI will be dropped sooner or later I created addons for Firefox and Chrome to get the same job done. In Firefox XPCOM and in Chrome (Native messaging host) allowed me to achieve the same for which I relied on NPAPI. Now, the only problem remains with Opera (Windows). It still doesn't support Native messaging host for invoking external application, so what is the alternative for invoking external app in Opera (15+)?
Does anybody know when Opera is going to support Native messaging host?
Opera does support native messaging from version 20 onward: http://dev.opera.com/extension-docs/tut_message_passing.html#native_messaging
Support for the Web MIDI API has been added to Chrome Canary since early 2013.
Why then, when I type requestMIDIAccess in the JavaScript console and hit enter, do I get "ReferenceError: requestMIDIAccess is not defined"?
According to official documentation, it should be a defined function.
What gives?
The Web MIDI API is available by default only in Chrome versions 43 and newer.
In earlier versions it is not enabled by default, but can be enabled as an experimental feature flag. In Chrome, load the special URL chrome://flags and search within the page for "Enable Web MIDI API".
The options on the flags page require the browser to be restarted before they will take effect. The features hidden behind these flags are in an experimental state and are subject to change at any time, so the API in older versions may differ from what is available in Chrome 43.
Note also that the requestMIDIAccess function is a method of window.navigator, not directly of window. Therefore you need to call it as navigator.requestMIDIAccess.
Also note that after you plug-in a new MIDI device, you may need to quit and restart Chrome. It does not seem to handle dynamic adjustment of the device list.
Is there a way through JavaScript or a web service to see if a plug-in installed in Firefox is being blocked by Mozilla? In particular, on my web site, I want to be able to tell if Mozilla is blocking an outdated version of Adobe Flash and adjust our UI accordingly.
The address that Firefox uses to download the blocklist is defined as extensions.blocklist.url preference:
https://addons.mozilla.org/blocklist/3/%APP_ID%/%APP_VERSION%/%PRODUCT%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/%PING_COUNT%/%TOTAL_PING_COUNT%/%DAYS_SINCE_LAST_PING%/
Fortunately, not all of these parameters are required, this address will work to download the current blocklist:
https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/21.0/
This is the ID of Firefox and the version number of the current release, so the blocklist could be different for other Mozilla applications and other Firefox versions. Looking through https://addons.mozilla.org/blocked/, there are some items listed as "for Firefox version n.n.n and higher", some are listed as "for Firefox and SeaMonkey" and others again as "for all Mozilla applications". Still, it seems that the blocklist for the current Firefox version should be the most complete one.
You can download and process this file in a web service, then adjust the behavior of your web application accordingly.