The DeviceOrientation specification includes a Device Motion Event. I've seen it run on an iPhone, and heard it is supported in Chrome Mac and used on the Google Jules Vern Doodle.
Is it supported in any other browser implementation yet? What versions did it become available in?
Supporting DeviceOrientation or DeviceMotion is a combination of the browser and the hardware it's running on. Both Firefox and Chrome on windows support DeviceOrientation in terms of having the API, but won't necessarily work on any particular hardware. Firefox supports DeviceMotion, but Chrome on windows doesn't.
On a lenovo thinkpad with 'lenovo airbag protection' running, Firefox 10 will provide DeviceMotion events, but strangely won't provide DeviceOrientation events. Also, the values it provides seem to be wrong (i.e. not measured in m/s/s). vAnd while Chrome has the DeviceOrientation API, I haven't been able to get it to provide events. Opera 11.61 on windows doesn't seem to support either API. Safari 5.1.2 for windows doesn't seem to support either.
An excellent page on using the DeviceMotionEvent is here http://www.html5rocks.com/en/tutorials/device/orientation/ which includes a demo using DeviceOrientation and another demo using DeviceMotion.
Related
We are writing a webplayer where we need to determine the DRM system supported by the browser. We used below code to check the DRM type on browser.
keySystems: {
clearkey: ['webkit-org.w3.clearkey', 'org.w3.clearkey'],
widevine: ['com.widevine.alpha'],
playready: ['com.microsoft.playready', 'com.youtube.playready'],
fairplay: ['com.apple.fairplay']
},
Chrome:
navigator.requestMediaKeySystemAccess()
IE:
videoElement.isTypeSupported()
We thought of using webkitGenerateKeyRequest() in Safari. But on Javascript console on Safari I tried to see whether the API is available.
let vel = document.getElementById('videoID');
but vel is not listing webkitGenerateKeyRequest() on Javascript console. Can I use can I use canPlayType() as per the answer Determine DRM system supported by browser .
The problem is it will say 'maybe' to everything instead of determining exactly whether the browser supports the perticular DRM or not. Is there any API to find the DRM supported by browser?
Unless you are using a non standard browser the mapping is quite simple usually at this time and you don't really need to check anything other than the browser type:
Safari - FairPlay
Chrome - Widevine
Internet Explorer - Playready
Firefox - Widevine
Mobile used to be a special case as Safari on iOS did not support FairPlay but it now does.
Beyond that, the standard way is to use requestMediaKeySystemAccess as you suggest - latest support picture is usually up to date here:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/requestMediaKeySystemAccess#Browser_compatibility
I want to develop a browser plugin for RTSP streaming on web browser, I read about NPAPI, which can execute native code(C++). But Google Chrome will not support NPAPI in future and no guaranty about Firefox also.
Please somebody can suggest me to "How can I develop plugin which can execute native code(OR any other language) using other framework instead of NPAPI?".
How can I add RTSP Streaming support for web browsers?
I'm afraid you cannot implement universal plugin at the moment. It's possible to write extensions for Chrome and Firefox which support TCP and UDP sockets (Chrome API, Mozilla API ). No such thing for Microsoft Edge or Explorer or Safari as far as I know.
If using different streaming protocol is an option, consider WebRTC. Its support is still not very good, but at least WebRTC is an official standard and has better chances of being adopted.
If you plan to develop an extension for the major browsers (IE, Firefox, Chrome and Safari) then I'd suggest looking into the kango framework. It takes a common code base and converts it into plugins for 3 of the 4 major browsers (for IE you'll have to contact them)
I have a need to differentiate between the native (Android) browser and Google Chrome on more recent Android devices, but keep running into problems, specifically with more recent Samsung devices (the Galaxy S4, Galaxy S4 mini and Galaxy Mega).
We have some device detection in-house which analyses the user agent sent from the browser to try and determine which browser is being used. Traditionally to detect Chrome, the code would look for either "Chrome" or "CriOS" within the user agent, normally these are present in the last part of the user agent string (according to the Wikipedia article on User agents, this is used to indicate available enhancements).
Up until very recently, this worked without issue*.
On the latest Samsung Galaxy devices (listed above) running Android 4.2.2, the native browser returns "Chrome" in the user agent string. From some brief reading around the subject, this is because the native browser uses Chromium (I'll admit, I didn't understand the differences between Chromium and Chrome until I read around the subject a bit, more info here).
This also invalidates the use of Chrome feature detection suggested here.
The main issue with this is that we're seeing minor rendering differences between the two browsers, which we'd normally handle with browser specific CSS hacks**, which we're now unable to use.
So far, we've only seen this issue on Samsung Galaxy devices, when tested on a Nexus 4 running Android 4.2.2, the native browser does not return Chrome as part of the user agent. It could be that this is a problem very specific to Samsung Galaxy devices running Android 4.2.2, but at this juncture, we don't have a broad enough range of devices to test on.
Does anyone know of any way of reliably differentiating between the two browsers without using either of the two methods above?
*that's without any issues that we've noticed or that have been reported to us.
**yes, I know using hacks isn't the best way of doing things, but when it's that or re-write large chunks of the code, hacks tend to win out.
Is there any reason to use AudioBufferSourceNode.start(...) over AudioBufferSourceNode.noteOn(...)?
Yes. start() will work in Mozilla's nascent Web Audio implementation, and will work in Safari in the future. noteOn() won't.
As of today NoteOn does not work in Google Chrome, so you must use start(). (2014-07-24)
(This should be a comment but I don't have the rep.)
My company's developers confirmed that noteOn() began to fail in browsers that use recent versions of WebKit, but that to start() is a reliable alternate. Sorry, I don't know the specific version of WebKit, but affected browsers include:
All native browsers for iOS 10.3 (and above). This is due to Apple's requirement to use WebKit on that platform, including Safari, Chrome, Firefox, and Opera. As an example of a non-native "browser", Puffin is really a remote-access portal to a LINUX window, so it is unaffected. (Apple recently pulled Puffin Academy from the store, but it may be a misunderstanding of the method used, or may be a tightening of their requirements.)
Safari 10.1 (and above) for Mac OS X 10.10 through macOS 10.12 (and above).
I'm trying to figure out what Javascript APIs I can use to achieve support for Mobile Safari back to iOS2. I haven't found a list anywhere that shows what version of Mobile Safari ships with each new version of iOS. I'm looking for a comprehensive list that goes all the way back to iOS2.
Thanks!
[Edit: Yes, I know and love feature detection. However, I have a set of targeted browsers I need to support, and I just need to verify that the fallbacks I provided cover my target audience and that I don't need to provide additional fallbacks that are cumbersome hacks).]
Since this is already the top hit on Google, we should start a list here. I'll make this answer a community wiki. By the way, I'm pulling these from the device's user agent string. Browser version is iOS version dependent, NOT device dependent. But when a phone doesn't support higher iOS versions it is listed:
3.2.2 - Mobile Safari 4.0.4
4.3.3 - Mobile Safari 5.02 - iPhone 3g
5.0 - Mobile Safari 5.1
5.1 - Mobile Safari 5.1
6.0 - Mobile Safari 6.0 - iPhone 3gs
7.1 - Mobile Safari 7.1 - iPhone 4
8.3 - Mobile Safari 8.0
9.2.1 - Mobile Safari 9.0 - iPhone 4s
10.3.4 - Mobile Safari 10.0 - iPhone 5
11.2.5 - Mobile Safari 11.0
12.1.4 - Mobile Safari 12.0
12.4.4 - Mobile Safari 12.1 - iPhone 5S, 6
13.0 - Mobile Safari 13.0
[...] - [...]
15.2 - Mobile Safari 15.2
This guy's list is really useful: http://www.somegeekintn.com/blog/stuff/iosvers/
If you need the additional info, you can decode the Safari versions on useragentstring.com, e.g:
http://www.useragentstring.com/Safari5.0.2_id_18120.php explains that Safari version 6533.18.5 is known as "Safari 5.0.2"
I couldn't find a comprehensive list either. The best thing I've found so far is some Safari documentation from Apple:
https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/OptimizingforSafarioniPhone/OptimizingforSafarioniPhone.html
Good luck!
[Update]
While this still doesn't answer the question it at least tells when WebKit added support for getBoundingClientRect() in Febuary of 2009.
http://trac.webkit.org/changeset/40837
Rather than doing device or os detection, you should be doing feature detection -- it'll provide a much richer experience, and you can provide custom code to add functionality that the specific version doesn't support. This way you'll provide support way beyond the specific devices you're targeting (and it usually ends up being easier since rather than branching your code for a specific user-agent, you're back-filling support for older js implementations by providing forward-looking support on a conditional basis).
For example, the latest version of desktop & mobile Safari do not provide .bind() functionality to bind a context to a closure. This can be detected and handled using Function.prototype.bind and if it doesn't exist, providing an implementation that provides the functionality to older browsers. Using a library like http://www.modernizr.com/ will assist greatly in this endeavor.
That being said there are some specific DOM events which are tied to certain versions of iOS:
http://developer.apple.com/library/safari/navigation/#section=Libraries&topic=Safari%20DOM%20Additions%20for%20iOS
If there are specific API's that you are looking at, caniuse.com is a great resource for finding out how far back the API has support.
Good luck with it!