I will first like to introduce myself since I am posting for the first time on the IEMobile blog. My name is Hiren and I work as a developer in the IEMobile team.  Most of the content in the this entry is targeted towards general Windows Mobile device users with a small section  at the end detailing IEMobile’s support for encoding detection targeted specifically towards web authors.

The Scenario:

Often times you want to be able to view web pages in a language different than the OS language for your Smartphone or PocketPC device. For example, a user may want to view pages in Japanese even though the default language for the device he/she is using is English. Web browsers support this scenario using an HTTP header called “Accept-Language” (defined in section 14.4 of HTTP 1.1 Header Field Definitions) which specifies a preferred Language for the web browser to the web server. If the server has the page available in the requested language the user will be able to view the page in that language which may or may not be same as the language for the device. For example, to set the preferred language to Finnish you could set the value of Accept-Language to “fi-FN” where the lowercase “fi” indicates Finnish and the uppercase “FI” indicates the country, Finland.

 That’s great. How do I set the Language?

IEMobile supports setting the Accept-Language header to a desired language via a registry key. You can set the following registry key to one of the acceptable language tags for the Accept-Language header. 

HKEY_CURRENT_USER\ Software\ Microsoft\ Internet Explorer\ International\ AcceptLanguage

 RFC 1766 defines the acceptable values for the language tag.  It refers to ISO 639 list for language codes and ISO 3166 list for country codes.  You can actually specify multiple different preferred languages and a quality value indicating the preference level for each of them as well. For details, please refer to the HTTP header documentation (section 14.4 of HTTP 1.1 Header Field Definitions).

Note:

 If the OS version you have supports this feature it does not matter if this key is not present by default in the registry. You should be able to create the registry key if it already does not exist and this will work.

Another thing to note is that you only need to enter the language code and not the entire header as the value of the above registry key. For example, “fi-FN” will be a valid value to set for the above registry key.

Which versions of the OS support this?

Only devices running Windows Mobile 2003 Second Edition ( including WM 5 ) or later support setting the accept-language header via the registry. This does not work for devices running older versions of the OS (even if you see the above key present in the registry).

Caveats

1.       You will need to reboot the device after you change the registry for the changes to take effect.

2.       You will also need to make sure you have the required font for the desired language installed on your device if you want to display pages in any East Asian languages like Chinese for example.

Switching between the two supported languages without changing the registry (Only for  Smartphones)

Smartphone devices actually support two different languages out of the box. You can switch between these two languages by changing the setting in Settings | Regional Settings | Language. For example, most of the English phones also offer German as the other available option in the above setting. The Accept-Language header value sent out by IEMobile respects the language specified in this setting. In other words, if you just want to switch between these two languages while browsing you can just change the above setting and you don’t need to modify the registry as mentioned above. However, if you want to view pages in any other language then you will have to user the registry method specified above.

Note:

If the above specified registry key exists then the language specified in the registry key takes precedence over the language specified via the setting in Regional settings.

Specifying the character encoding for pages ( Target Audience: Web Authors )

A related topic for web authors is how to mark a page with a specific encoding so that the browser understands which encoding the page uses. HTML 4 specification section 5.2.2 mentions different ways of marking the character encoding for a page. IEMobile follows the standard as mentioned in section 5.2.2 for the most part. Specifying the “charset” param on the “Content-Type” header or a META declaration with “http-equiv” set to “Content-Type” works as mentioned in the standard. However, the 3^rd method of specifying the encoding on a per element basis by setting the “charset” attribute on the element tag is not supported.

Detecting the encoding of the page based on the byte order mark (BOM) is only partially supported.  IEMobile supports detection of utf-8 BOM header but utf-16 detection via BOM is not supported. However, utf-16 encoding can be used if the page is explicitly marked as such by the above mentioned supported methods.

-          Hiren.

Hi this is Dave, the Test Lead for IE Mobile.

Yes, there is an Adobe Flash player for Pocket PC.  The Adobe Flash Player 7 for Pocket PC (sorry Smartphone users) works on a ton of sites but there have been some complaints that it doesn’t work everywhere.  The reason for this discrepancy was not openly clear so the IE Mobile Test team decided to conduct an investigation.

Our investigation quickly revealed some common issues:

·         Many sites used a commonly shared JavaScript sniff for Adobe Flash support.  This JavaScript would than write out VBScript to detect Adobe Flash support and appropriately render the ActiveX control object for Flash *or* some alternative non-Adobe Flash content. 

Ø       Unlike desktop IE, IE Mobile does not support VBScript and it is unlikely that we would add support because it would increase our memory footprint by as much as 400K.

·         We also found a few rare cases of the use of the <embed> tag to host variables for Adobe Flash object.

Ø       <embed> is not is not a part of the HTML 4 or xHTML 1 specifications and as of right now, IE Mobile does not support it.

Adobe’s warnings about using JavaScript:

http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14526#builtin

“Ease of use makes script-based detection the method of choice for most people. However, the drawbacks are significant.”

Examples of what not to do:

Here are some commonly used problematic JavaScript examples pulled from real websites. 

…

else if (navigator.userAgent && navigator.userAgent.indexOf("MSIE")>=0 

   && (navigator.appVersion.indexOf("Win") != -1)) {

        document.write('<SCR' + 'IPT LANGUAGE=VBScript\> \n'); //FS hide this from IE4.5 Mac by splitting the tag

        document.write('on error resume next \n');

        document.write('FlashCanPlay = ( IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.")))\n');

        document.write('</SCR' + 'IPT\> \n');

}

…

Or

…

// Check the browser...we're looking for ie/win
var isIE = (navigator.appVersion.indexOf("MSIE") != -1) ? true : false; // true if we're on ie
var isWin = (navigator.appVersion.toLowerCase().indexOf("win") != -1) ? true : false; // true if we're on windows


// This is a js1.1 code block, so make note that js1.1 is supported.
jsVersion = 1.1;

// Write vbscript detection on ie win. IE on Windows doesn't support regular
// JavaScript plugins array detection.
if(isIE && isWin){
document.write('<SCR' + 'IPT LANGUAGE=VBScript\> \n');
document.write('on error resume next \n');
document.write('flash2Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.2"))) \n');
document.write('flash3Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.3"))) \n');
document.write('flash4Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.4"))) \n');
document.write('flash5Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.5"))) \n');
document.write('flash6Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.6"))) \n');
document.write('flash7Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.7"))) \n');
document.write('flash8Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.8"))) \n');
document.write('flash9Installed = (IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.9"))) \n');
document.write('<\/SCR' + 'IPT\> \n'); // break up end tag so it doesn't end our script
}

…

Or even this:

…

else if (navigator.userAgent && navigator.userAgent.indexOf("MSIE")>=0 && (navigator.userAgent.indexOf("Windows 95")>=0 || navigator.userAgent.indexOf("Windows 98")>=0 || navigator.userAgent.indexOf("Windows NT")>=0 )) {

  var tVersionString = "";

  document.write('<SCRIPT LANGUAGE=VBScript\> \n');

  document.write('on error resume next \n');

  document.write('set tSWControl = CreateObject("SWCtl.SWCtl") \n');

  document.write('if IsObject(tSWControl) then \n');

  document.write('tVersionString = tSWControl.ShockwaveVersion("") \n');

  document.write('end if');

  document.write('</SCRIPT\> \n');

…

The common problem is that the UserAgent sniffs allow IE Mobile to pass through because we have ”MSIE” and “Windows” in our UserAgent.

IEMobile’s UserAgent values:

http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx

• Our old UA: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)

• Our new UA: Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 6.7)

Example of the use of <embed> tag.  Please don’t do this.:

<a href="http://fakesite.com/index.htm">" Title for control</a><br><embed enableJSURL="false" allowScriptAccess="never" allownetworking="internal" enableJavascript="false" allowScriptAccess="never" allownetworking="internal"    enableJavascript="false" src="http://fakesite.com/sample.swf" flashvars="m=1368734076&type=video" type="application/x-shockwave-flash" width="430" height="346"></embed>

How can site owners make sure that Adobe Flash will work on IE Mobile?

Adobe’s Recommendation:

How to detect the Flash 4 Player without using JavaScript

http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_14086

“This approach to Flash Player detection relies on two key elements; a Flash plug-in "sniffer" that uses the GetURL action which only the Flash 4 Player will respond to, and an HTML page with a META refresh tag. The index page of the site will use a Flash movie to detect for version 4 of the Flash Player and direct those browsers to the Flash 4 content. If the user hits the index page either without the Flash Player or with version 2 or 3 of the player, the META refresh tag will automatically send them to a non-Flash page which will prompt them to download version 4 of the Flash Player. This scheme works without using any JavaScript, making it both simpler and more browser-compatible.”

IE Mobile’s recommendation:

We are not hopeful enough to think that sites that use JavaScript for Adobe Flash detection are going to switch over to a non-script dependent method just because Adobe Flash doesn’t work on IE Mobile.  We are just not a big enough player.  Our best hope is to ask site owners to slightly modify their existing site code to allow Adobe Flash to display on IE Mobile. 

Our research determined that the easiest way for Adobe Flash to work on IE Mobile is to add an additional “else if” statement, to their existing JavaScript, to specifically sniff out IE Mobile (Look for “CE” and “Win”) and than to allow for the ActiveX Adobe Flash control to render.  The existing desktop browser sniffing logic will continue to work and in just a few lines of code you give support to IE Mobile.

I know what you are thinking.  “What if you’re using IE Mobile on a SmartPhone? There is no Adobe Flash Player 7 support for SmartPhone.” or “What if the PPC device doesn’t have the Adobe Flash player installed?” 

It is clear that our recommendation is not ideal because we risk not displaying the alternative “non-Flash” content that I mentioned at the top of the Blog.  Realistically this situation is no worse than today’s experience because we are not displaying the Adobe Flash or the alternate non-Flash content on these sites already.

We could make the first example from above work by entering in the green “else if” statement below:

…

else if (navigator.userAgent && navigator.userAgent.indexOf("CE")>=0

   && (navigator.appVersion.indexOf("Win") != -1)) {

                        FlashCanPlay = true;

}

else if (navigator.userAgent && navigator.userAgent.indexOf("MSIE")>=0 

   && (navigator.appVersion.indexOf("Win") != -1)) {

        document.write('<SCR' + 'IPT LANGUAGE=VBScript\> \n'); //FS hide this from IE4.5 Mac by splitting the tag

        document.write('on error resume next \n');

        document.write('FlashCanPlay = ( IsObject(CreateObject("ShockwaveFlash.ShockwaveFlash.")))\n');

        document.write('</SCR' + 'IPT\> \n');

}

…

I hope this helps.

Dave

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

Every so often, I see a report that IE Mobile is not caching web pages on the device. Upon investigation, it turns out that the reporter notices the empty directory “\Windows\Temporary Internet Files” and assumes that is the location of the cache. It is not: the cache is located, by default, at “\Windows\Profiles\guest\Temporary Internet Files”.

You can change this location, as well as the location of history and cookies, by editing the value of the registry keys found here: “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders”. There is one key for each of cookies, cache, and history, and each value is a string representation of a path.