Detecting browser versions on recent mobile devices - javascript

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.

Related

How to interpret caniuse website information?

I wanted to check what is the support of fetch API in browser so I opened caniuse.com to get this information.
Looking at Chrome browser I see this feature is available since version 42 (which released in april 2015), but looking at Chrome For Android and I see only version 84.
Does this mean that fetch API is available only in the latest version in Chrome For Android? That doesn't seem logical to me so what is the correct way to interpret this (and other) tables on caniuse.com website?
Caniuse hides browser versions with less than 0.5% percent of users, which you can check and tweak by clicking on settings. That spawns a sidebar. You can lower this number down as fast as 0.01%, but even then Chrome for Android only shows version 84. That is because so many people have automatic updates turned on, that at least for mobile browsers, it's much more likely that people are on the latest version. For desktop browsers, people have to deal with company guidelines, have to go through the trouble of clicking "update", etc.
So in conclusion, if a version is not shown, even at 0.01% in the settings, consider it non-existing.
What happened here is that there is no specific data for Chrome for Android, so caniuse defaults to saying that if it's supported in the latest desktop version, then it's also supported in the latest Android version. Nobody has taken the time to specifically test Chrome for Android.
In general, caniuse is a human-curated list and won't always be accurate. You'll be best served by tracking down more primary sources. For example, the Fetch API was enabled in Chromium in 2015-02, with no platform-specific exemptions.

Speech Synthesis API supports a language on the phone but not on desktop

I am about to use Speech Synthesis API in an ongoing project, and before moving on I was about to collect as much data/demo on web as possible.
Hereby an example, but the phenomenon is always the same, regardless the demos I tried: http://labs.qnimate.com/speech-synthesis-api/
So, the point is, that on my mobile, I can choose 'hu-HU' but, as it seems to be it is not a possibility on PC (Chrome as well).
Chrome Versions:
Mobile: 50.0.2261.89
Desktop : 50.0.2661.94
Any idea, what causes the difference?

Building website for Windows mobile 6.1

I am making a website for windows mobile phones 6.1 and trying to figure out which browser to use. I have ran into a pattern that some functions that run on 1 browser don't work on another. So far I have tried
IE 6 - relatively better but bad alignment and page is zoomed in when opens
Opera Mobile 10 - Javascript keypress does not work, Although good alignment and screen resolution settings
Mozilla Fennec - Best one so far but is really really slow.
Any ideas if I update IE/OS on these phones to solve this, I am trying to avoid buying new licenses?
Developing web sites for Desktop or Mobile is always a challenge with all the different browsers.
If you intend to use a batch of one mobile device model, you can define which browser has to be used. If you are not in that position, you have to work against different browsers.
On windows mobile 6.1 the only standard you can rely on is the built-in IE6 mobile browser.
If you can define a 3rd party browser, you may have a look at ZetaKey (based on WebKit).

is Mobilizer capable of emulating perfectly the behavior of scripts as well?

I recently took a look at Mobilizer http://www.springbox.com/mobilizer/
It's pretty amazing, being able to simulate the interfaces of iphones and stuff.
However, my question is that is it actually capable of rendering the exact same behavior not just for layout but for the javascript scripts?
I mean it will pretty hurt to find out that the script ran correctly in the emulator only to fail in the real scenario...
This program will not emulate the actual phone OS. As far as I can tell, it is just loading up the page in an internal (desktop based) browser and displaying it within the phone with the correct dimensions etc. It is probably sending the User Agent string that belongs to that device as well.
So, It is useful for testing your layout on different screen sizes, testing your mobile redirect scripts and saving out mockups of the website on a device for clients.
It is definitely not to be used to test if your website will work on that device.
To accurately test without a physical device on:
iOS, check out the iOS simulator that comes with X Code.
Android, check out the Android emulator that comes with the Android SDK.
WebOS, check out the WebOS emulator from the webOS SDK
Blackberry, check out the Blackberry Simulators (Windows only)
Unfortunately, there is no app that makes testing on all these devices easy as it seemed 'Mobilizer' did. If you can, it's always good to test on the actual devices too as emulators aren't always perfect.

Are JavaScript getters/setters supported by Mobile Safari on the iPad?

I'm developing an iPad Web App for a client. Unfortunately I don't have an iPad to test the app, so I tried testing it on my iPhone. I entered the following URL in Mobile Safari and it alerted me that the method is undefined:
javascript:alert(Object.defineProperty);
I need to know however if it'll work on the iPad. Additional information about getter/setter support on the iPad is appreciated.
I've only tested 4.3, but it looks like it is supported for JS objects, but not DOM objects... just to be different from IE8 which is the opposite.
If you have access to OSX, I recommend downloading XCode --it comes with a useful iOS emulator for the various devices.
Also, this link might be useful, as it contains a table of ECMAScript 5 features, even though it does not mention the DOM restriction.
http://davidbcalhoun.com/2011/new-mobile-safari-stuff-in-ios5-position-fixed-overflow-scroll-new-input-type-support-web-workers-ecmascript-5

Categories

Resources