IEMobile Team Weblog

Information about Internet Explorer for Windows Mobile

Detecting Internet Explorer Mobile's User-Agent on the server

Changes afoot:

We recently made a change in the next version of IE Mobile for Windows Mobile, regarding the IE Mobile User-Agent string.  It was a little (ok - a lot!) out of date, and it really didn't suit our needs.  It was a relic of a long ago fragmented product that just didn't reflect the current state of the browser.

What we discovered as we updated the string was that many sites that thought they were properly detecting IE Mobile really weren't doing it the right way.  Our own MSN sites had a few problems, which they're updating, so that they'll be ready to go when the new crop of devices hits the market.  We've even talked to some very friendly fellows at a big, popular rival search engine company and made sure their seach page will render right when these devices ship.

In the interests of helping fix the broken sites out there now, and getting people ready for the future, we're releasing our new User-Agent string right here, along with a pointer to some other information.

Out with the old:

For Windows Mobile 5.0, our "current" release, the User-Agent header that the browser sends across is one of the following two strings:

  • Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)
  • Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; Smartphone; 176x220)

Some of the really broken sites we've seen were looking for the resolution information, and using that to deliver a mobile page.  That's wrong, because that information may be absent on some devices from the User-Agent string (more about that in a minute...)

Others were using one of many badly written samples out there on the net, finding only, "MSIE 4.01," then kicking the browser out of the site, because they wanted IE 5.5 or IE 6.0 only.

If you want to detect the current/older IE Mobile browsers, the way to do it is to look for "PPC" or "Smartphone", as well as "Windows CE" in that string.  That's the only sure-fire way to be certain of what you're getting.

In with the new:

Moving forward, here's the new IE Mobile User-Agent string:

  • Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile m.n)

The "m.n" portion is a version number, like "6.7", which can help you page and site authors address feature set.  It also lets us know what to look for when debugging our customer's problems, as each manufacturer often gets a slightly different variant of Windows Mobile with a lot of QFEs for their specific needs.  When this new browser makes it into the "wild" on devices, we'll let you get a list, likely via MSDN, of what we update for each release, so you can decide if you want to take advantage of the new features.

If you want to detect the new browsers coming out, just look for the string "IEMobile" as part of the User-Agent header.  Since the capabilities of the Pocket PC and Smartphone versions of the browser are identical, and they're built from the identical code base, there's no reason to differentiate them any more. 

Mixing it up:

We're also being a little more hard-core about modification to the string.  In the past, OEMs and mobile operators could change this string.  We've locked it down now, although they can still append to it, after the closing parenthesis.  We feel that it's really important that page authors can truthfully and honestly detect IE Mobile, but we still want to allow our OEMs a little room to add additional package information, device strings, or whatever to that header.  We just don't want to delete things that are really important, like that "IEMobile" information!

Getting the big picture:

At first glance, it might look like we removed useful stuff from the User-Agent header, but that's not the case.  We've always sent a batch of additional headers along that contain all the good stuff, which you should use if you need more information to render a page properly.  They're designed for this type of work; sniffing the User-Agent isn't.  We've got information available as to screen size, color depth, operating system, CPU type, and even if VoIP is supported.

The additional headers we send are:

  • UA-pixels: {i.e. 240x320}
  • UA-color: {mono2 | mono4 | color8 | color16 | color24 | color32}
  • UA-OS: {Windows CE (POCKET PC) - Version 3.0}
  • UA-CPU = {i.e. ARM SA1110}
  • UA-Voice = {TRUE | FALSE}

These headers have been around (other than UA-voice) since at least Windows Mobile 2002, and their purpose is to help you make rendering decisions if you have to do layout adjustments.

Note that on Smartphones, we may not have the UA-CPU information; it's a privileged API, and we run unprivileged, for security purposes.  The newer release will fix this, as we can at least tell you ARM or X86 builds, even if we can't locate the processor specifics. 

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcepie/html/ceconidentifyingpocketinternetexplorertowebserver.asp has more information about these headers and using them with Internet Information Server.

In our latest update, UA-pixels, which has the screen size, will also change with portrait or landscape rotation, and, on HiDPI devices, which are capable of changing to high or low resolution, if the user changes the device screen size, the UA-Pixels header will reflect the change, as well. 

Getting it exactly like you want it:

There's one more bit of information for page authors, and that's a particular META tag.  If you want, you can build your page with:

  • <meta name="MobileOptimized" content="width">

Setting it on your page can turn off all of our layout optimizations and do them all server-side or in HTML yourself, if you really want to be particular about how things look.  More information, including a full set of parameters for the content field, is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce51conLayoutMetaTag.asp

That tag, in particular, tells us to skip our fit-to-screen rendering decisions, and just view the page in the equivalent of "Desktop" view mode.  It's really useful if you try to build pages or sites that are targeted towards mobile end users.

-Cameron

 

Published Thursday, August 03, 2006 7:48 PM by iemoblog

Comments

 

Chiefie said:

looks like the future for optimising a website for windows mobile users will be easier... especially the separation of screensize from the UA.

Certainly welcome this.

NOW if only screensize report in UA can also be implemented in all other browsers (i.e. desktop) that will be great!!!!!
August 8, 2006 10:10 PM
 

Derek said:

That is great information!  The new format is good, and I didn't know about the additional UA headers.
August 11, 2006 1:42 PM
 

Ken said:

Nice work -- and glad you kept the information in the other headers -- we use it to help customers know if they have a Pocket PC or Smartphone (it's hard to tell just by looking with some of the newer devices).
August 15, 2006 1:08 PM
 

Mahadevan said:

" In the past, OEMs and mobile operators could change this string". This is true and I faced this problem delivering content to my client. I checked exactly for the USer agent string and it failed and on inspection, i founf that hp added the model number to the String and dopod also added the model.
Then I just checked for the test PPC and Windows Ce and deliverying the content.

Locking the string is one good step.
August 24, 2006 10:54 AM
 

maccoy said:

Hey guys Is there I can change the HTTP header Accept-language in Pocket IE, is  it already possible or you guys will have any plans to add that.
August 24, 2006 10:58 AM
 

wallace said:

One thing I need to remind you is many operators have developed server side codes to recognize the device model by the old style UA-String. And some of them relied on the capability to replace the entire UA-String. This change will fail all those existing codes and a rework is required.
September 4, 2006 5:08 AM
 

raybro said:

Thanks for the information.  We have been using the Windows Mobile 5 emulators and see the connect string as  Mozilla/4.0+(compatible;+MSIE+4.01;+Windows+CE;+Smartphone;+176x220)  Apparently the .Net mobile controls get confused when the device is really 320x240.  Any relief in sight for having the emulator actually use the string that matches the emulated device?  Especially in the new format.

Thanks

Ray
September 12, 2006 10:30 AM
 

iemoblog said:

We are fully aware that some people detect IE Mobile (or try to) on the server.  What we found through our testing was that more people did it improperly than correctly, hence most of the focus of this blog entry.  We also have need to control this string for a variety of reasons.  There will be some rework required by a small minority of operators, and a large contingent of sites.  

In the end, though, it's our opinion that the pain inflicted by the change now is worth it. In the large majority of cases, it improves the overall browsing experience, as many of the sites detecting IE Mobile incorrectly considered it IE 4.0, which it isn't...but that was the last time the string had changed.
September 12, 2006 6:04 PM
 

iemoblog said:

Raybro -

Until you get the next release of Windows Mobile, you won't have an emulator build of the browser that will have the new string.  You can use the old method and replace the entire key in the registry with the new version copied from the text above.  See: http://www.pocketpcmag.com/FORUM/topic.asp?TOPIC_ID=17223 for details of how to change the string on current/older generations of IE Mobile.
September 12, 2006 6:07 PM
 

Ridwaan said:

i no that with the old method yu can adjust the user agent and it will allow you access webpages with idetification of a desktop PC.

but i am unable to solve a wierd problem on the network with my PPC, when i try to open any website on pIE with user agent string Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320) it opens halfway and stalls on 1kb, the page does not continue loading.

will the new user agent make any positive change on this annoying browsing problem ? or is my problem something else completely ?

October 4, 2006 10:42 PM
 

Younes said:

Is there a way to detect if the Smartphone version of IE supports frames from the server-side. I know that SmartPhones with WM 5 and a certain ROM version support frames, but I'm not sure what to look for in the headers (OS Version?)

Thanks,

Younes

October 30, 2006 6:09 PM
 

kdarling said:

I understand why you have it lie about the IE version, so that websites will let you in.

It's too bad that had to happen, especially since IEM is more like IE 3.2 or less, in its current state.   We watch for IE 6 in our industrial application so we know whether we're dealing with real IE 6 on laptops or Windows CE or not.   No way will our IE 6 code run on IEM.   We'll have to recode to look for the other clues to see if the IE version is a lie or not.

On another note, what's the effect of the Deepfish browser on IEM development?

For PDA and phone users, I'd rather see Deepfish.   For industrial purposes, I'd like to see either IE 6 on WM devices as an option (why not?  who does it hurt?), or an IEM that's targeted for writing HTA-like apps.

Thanks,

Kev

April 1, 2007 1:05 PM
 

prc said:

I'd also like to be able to control the vertical use of the screen, but can't find a way to either a) determine whether the browser is in full screen mode or b) force the browser into full screen.

It seems that screen.height gives the total screen size, while screen.availHeight gives the height minus the top/bottom bars (regardless if they are visible or not).   Is there anyway to find out how much space is actually available?

Related question:  is it possible to know (or control) what level of "zoom" the user has selected?

April 12, 2007 11:06 AM
 

kjgerard said:

"I'd also like to be able to control the vertical use of the screen, but can't find a way to either a) determine whether the browser is in full screen mode or b) force the browser into full screen."

Please relay if this functionality been determined.   That is, the ability to force the Pocket IE browser into full-screen mode.  

May 12, 2007 11:30 AM
 

noter said:

I use ToggleIE to change the referrer on the mobile device. It allows you to change the referrer to Opera, Firefox or IE

http://thinkabdul.com/2007/04/24/togglepie-freeware-to-change-windows-mobile-pocket-internet-explorer-mobile-browser-referreridentifier-string-to-that-of-operamozilla-firefoxie6ie7/

May 20, 2007 6:26 AM
 

iemoblog said:

kjgerard,

You can't set or query for full screen mode via an HTML document.

June 7, 2007 10:33 AM
 

randeepgabri said:

With this new string on MSIE 6.0, how we will find out that it is a PPC or Smartphone.

June 21, 2007 8:30 PM
 

iemoblog said:

randeepgabri,

You can distinguish between PPC or Smartphone using the "UA-OS" HTTP header.  It should read something like "Windows CE (Smartphone) - Version 5.2" or "Windows CE (Pocket PC) - Version 5.2".

June 22, 2007 8:00 PM
 

cmpandian said:

I have been trying to use the Windows Media control into a HTML page using OBJECT and EMBED tag to play a video clip available in my application server. But I couldn't.

I am using Windows Mobile 5.0 device (PPC Phone edition)

I tried the samples given at the link http://www.microsoft.com/downloads/details.aspx?FamilyID=46BA698A-C00D-4B90-9177-460854F1B57C&displaylang=en

But I am able to play a video providing a link to the video file using ASX entry; Using this method, when I click the URL, the browser will open a Media player and play the video clip that URL is point to. But I want to play a video using embeded media control. How is that possible? Is there any code samples available?

Or Any security issues to embed a windows media player into a HTML page? Any document related to this?

Thanks,

Pandian.

August 13, 2007 7:52 AM
 

iemoblog said:

pandian,

The sample seems to work here.  Is it really opening the media player, or are you just seeing the video full screen?  The sample plays full screen.  If you change line 92 in webapp.html to "wmpocx.fullScreen = false;" it should play inline.

August 16, 2007 2:57 PM
 

The Windows Mobile RSS (Reed and Steve Stuff) Feed said:

I have touched on this topic in the past, but it seem to be generating quite a few questions on the “make

November 2, 2007 8:19 AM
 

Noticias externas said:

I have touched on this topic in the past, but it seem to be generating quite a few questions on the

November 2, 2007 9:09 AM
 

The Windows Mobile RSS (Reed and Steve Stuff) Feed said:

The Web Browsing experience has really heated up for mobile devices over the last year or two. &#160;

December 9, 2008 8:33 AM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker