Hey, I was recently testing this script on my site for two purposes:
1 - detecting mobile devices to give users the mobile template, and
2 - detecting older browsers to wanr users to upgrade for HTML5 features.

I only have IE9 on my windows 7 desktop, so i switched IE9 into IE7 compatibility mode.

The script correctly detected IE 7.0 running on Windows 7, but called my device a "Zune 4.7". and returned "mobile" as the "ua_type".

The User Agent String for IE9 (9.0.8112.16421 64-bit edition) when in IE7 mode is below:



fixed version:


Hopefully there is an easy way of determining that "Zune" is just a compatibility option, not the actual device... i.e. it knows I'm running windows 7, Zune doesn't run windows 7?

I read a great article about reverse detection here that decides if we know for sure that we're on a desktop, we don't need to go any futher under know conditions...

notnotmobile.appspot.com

Hope we can find a way to fix this as the only way most modern windows users have of testing old browser compatibility is via compatibility mode.

(Awesome script btw - thanks!)

Regards,
James.
Back to top

Are you certain that your useragent string is standard? The '+' instead of spaces make me wonder, though that might be just some output thing on your end.

I've never seen a msie user agent with zune in it, any idea why that that is there? Are you sure that's not something you installed while doing dev on something or other to test?

Oh, wait, I found it, if you install zune software on your desktop, Microsoft, in their infinite (non) wisdom, adds zune to the useragent string of msie, thus making identifying actual zune devices just that much harder. Why they do that is totally beyond me.

stackoverflow.com/questions/10452117/ie9-erroneously-redirecting-to-mobile-site

stackoverflow.com/questions/5465584/what-is-ie9-compatibility-view-in-ie9-developer-tools



It looks to me like the best quick fix is to just remove zune from the list of mobile devices and leave it at that, assuming that basically nobody out there is going to surf on a zune, which is not a bad bet, given very few people even bought them.

I'd need to get a unique identifier for actual zune devices to work around this.

Microsoft really has a problem with dumping all this excess verbiage into the msie user agent string, that's caused problems for a long time, particularly when the embed an msie 6 ua string inside of the newer ua string.

However, it should be fixable, I just need to find an actual true zune device user agent, if it exists.

His not a mobile script will not be right with at least Linux, there have been mobile os that were not android but where linux. It's likely, but not certain using only that parameter to filter.

It's going to get progressively more difficult to know what the system is, as tablets spread, and the lines between small screens and larger screens blur.

I haven't, for example, seen a surface ua yet, that will be windows 8 running some browser, don't know what.

In a perfect world we could file a bug report with microsoft, they'd go, oh, of course, yes, we don't want our users on desktops to be directed as our own zune device, let's fix that. Sadly, we don't live in a perfect world, and MS continues to be sloppy and careless with its web products. So very familiar,

blogs.msdn.com/b/ieinternals/archive/2009/10/08/extending-the-user-agent-string-problems-and-alternatives.aspx



that's quite a bit of nonsense there, he tries to pretend that adding registry tokens to what is supposed to be a browser identification string used by servers on the internet is not a major bug that should be terminated asap.

It ends with this:


so there you have it, the bug was FIXED but left in place for legacy mode. I didn't know, though I have experienced problems caused by this bad decision made by ms years ago, but I am glad to see it finally fixed, a decade too late, but better late than never.

Hard to know what to do with that, I think it's best to get a few real zune ua strings and find out what makes them truly unique given that MS contaminated their ua strings with their own companies device name.
Back to top

Ahh, that explains quite a lot.

I'll try and see if I can get my hands on some real Zune UA strings (someone here must have owned one at some point...)

For now, I'll remove "zune" from my local copy for testing and we'll see if it actually affects the site once it goes live.

Thanks for your help - much appreciated.

Regards,
James.
Back to top

I'm thinking to do a secondary search for net clr in the string if zune is detected, and if it's present, to ignore the zune detection.

In the browser detection script, I try to avoid heavy regex because it's much more demanding on the server than running simple string searches. I do use some where it can't be avoided, but in general I want to detect a constant in a string, not a pattern.

blogs.oucs.ox.ac.uk/listeningforimpact/2011/02/16/user-agent-analysis-part-2-name-those-agents/

this guy seems to have a good grasp on the problem of identifying some complicated user agent strings.
Back to top

This bug is corrected in 5.4.10 browser detection.

The fix was actually easy, is mobile if not zune or if string contains iemobile, which the real zune string does, I think, at least the ones I have do.

I doubt anyone will ever actually report a failure in this case, but if you do, make sure to provide the actual zune device string.

This is good enough for now, given how few people probably surf on zunes in the first place.

I did see some zune device strings that were not false and also had no iemobile data in them, but I just can't find any reliable source for the actual zune browser strings out there, none of the regular resources I use have it.

Here's a real zune user agent string, but it's a bit old so I don't know what the new ones look like:

Back to top