Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Added detection for the newly announced Opera 14 which runs on the ne…

  • Loading branch information...
commit 6e66664b79a1313a0b32315620377f85fa3383a0 1 parent 656f407
@3rd-Eden 3rd-Eden authored
Showing with 10 additions and 0 deletions.
  1. +4 −0 regexes.yaml
  2. +6 −0 test_resources/test_user_agent_parser.yaml
4 regexes.yaml
@@ -61,6 +61,10 @@ user_agent_parsers:
- regex: '(Opera Mini)/att/(\d+)\.(\d+)'
- regex: '(Opera)/9.80.*Version/(\d+)\.(\d+)(?:\.(\d+))?'
+ # Opera 14 for Android uses a WebKit render engine.
+ - regex: '(?:Mobile Safari).*(OPR)/(\d+)\.(\d+)\.(\d+)'
+ family_replacement: 'Opera Mobile'
# Palm WebOS looks a lot like Safari.
- regex: '(hpw|web)OS/(\d+)\.(\d+)(?:\.(\d+))?'
family_replacement: 'webOS Browser'
6 test_resources/test_user_agent_parser.yaml
@@ -604,6 +604,12 @@ test_cases:
minor: '53'
+ - user_agent_string: 'Mozilla/5.0 (Linux; Android; 4.1.2; GT-I9100 Build/000000) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1234.12 Mobile Safari/537.22 OPR/'
+ family: 'Opera Mobile'
+ major: '14'
+ minor: '0'
+ patch: '123'
- user_agent_string: 'SomethingWeNeverKnewExisted'
family: 'Other'

13 comments on commit 6e66664


I question if it makes sense to include the WebKit-based Opera for Android in the Opera Mobile family. It's a totally new browser, and its name is "Opera", not "Opera Mobile". Creating a new family, such as "Opera for Android" makes more sense here.


@andreasbovens Just because the of Opera changed doesn't make it a completely new browser. It's still an Opera browser for Mobile only at this point. So classifing it as Opera Mobile made sense for me. As for Opera for Android It doesn't make any sense at all to add the operating system to the family name. If you want operating system data you should use the OS parser in combination with a browser parsers.


Why do you then differentiate between Chrome Mobile and Chrome Mobile iOS?


I honestly don't know, maybe @tobie can shed some light on that. But I'd remove it as it adds no value as it's detectable through the OS parsers


Thanks for catching that, @andreasbovens. @3rd-Eden, the reasoning here is that these are two completely different products, it's not just the same browsers with different platform bindings, but effectively a different browser produced by the same company. Maybe @elsigh and @dmolsen can chime in with their own point of view. I'd argue we should fix this and call it "Opera Android" or something.


So, what shall we do here?


@andreasbovens, @3rd-Eden and I chatted briefly about this on irc, and we seem to be in agreement that we should treat those as two different browsers. I just want to make sure we have a good strategy as to how to differentiate the mobile browsers from the desktop ones, and the mobile browsers between one another. Your input would be very valuable, here.


The main problem here are the different use cases that need to be supported.

You have Chrome Mobile which uses their own Chromium/v8 engine rendering on iOS you also have Chrome Mobile has the same look, feel and user experiance as the version on Android but it runs through the iOS WebView so it uses the render/JS engine provided by iOS. You can argue that they are different browsers because they have different engines. But you can also see them the same browser as they are both known to users as Chrome mobile.

If you use user agent parsing for anaytics it could make more sense to have no difference between Chrome Mobile on android and on iOS. You just want to know how many Chrome Mobile users you have and what platforms they run on (which is done by operating parsing).

For detecting and patching glitches in browsers it might be easier for developers to have a different name for iOS that they can test against.

What I talked about with @tobie is to maybe introduce an extra field that can be used to tell the difference between render engines. So you have a uniform browser family which is not dependent on the engine and still have more specific differentiating information about the browser to figure what kind of browser it is or what kind of engine it runs on (webview or mabye a proxy server like opera mini)


It's extremely difficult to find the right boundaries, here.

E.g. we're making a clear distinction between Opera Mobile and Opera Mini. Arguably, they're different products with vastly different capabilities, yet they're both running the same rendering engine.

We're making clear distinctions between Desktop and Mobile browsers, yet some have quasi similar capabilities (eg. Chrome desktop and mobile on Android). Etc.

TBH, I think the best strategy here (for now) is to continue the way we've handled that so far: make a distinction where it best makes sense. E.g. Opera Mobile and Opera Mobile for Android are vastly different products capability wise) and we should distinguish them.

We might change that later once/if we account for rendering engine.

Another strategy could be to provide a set of higher level definitions (e.g. mobile browsers made by Opera), but this might be better done elsewhere.


If you are gonna make an Opera Mobile for Android you would have to the same for when they release their WebKit backed engine for desktop browser as they would have the same distinction. Is that gonna be named Opera desktop for Mac or Opera Webkit? I don't think this makes sense at all to differentiate here.

I think we are forgetting here that this is actually just an iteration of Opera which is clearly marked with a different version number and that eventually all Opera browsers are going to share this WebKit engine and as this is the path that Opera decided to follow I would make sense to just keep the product name that Opera decided to give it or we will end up with an oddly named Opera for Android in the nearby future that just has the same feature set as the rest of the Opera's.

But in the end it's your call @tobie


So your point about this being a change in an existing product rather then a new product is a good one. This contrasts with Chrome Mobile for iOS, which is a new product which is going to co-exist with Chrome Mobile.



Let's try to approach this from another angle: how is the ua-parser library being used by developers? Is it just to say: "this is Opera, and (based on another test) its capabilities are x, y, z" or do some devs rely on ua-parser's browser family grouping to send different UAs down different code paths?


@andreasbovens: I have no idea. :(

Please sign in to comment.
Something went wrong with that request. Please try again.