Common problems with .NET CF WebBrowser controls

0.00 avg. rating (0% score) - 0 votes

Although most .NET developers will immediately think of the WebBrowser control when it comes to displaying HTML-formatted document, that seems to be more true for the full .NET framework rather than the compact framework. In fact, if your smart device application has to support a wide variety of devices, below are some reasons why the use of the WebBrowser control is discouraged:

1. Inconsistent HTML support across different devices. Although simple formatting like bold, italic, underline and tables tend to work well, more complicated constructs (css, javascripts) will be dropped or simplified by many devices. There is no way to know for sure except for testing.

2. WebBrowser.Navigate() opens a new window. On many devices, especially on devices where Opera is the default web browser, calling WebBrowser.Navigate() on a local file will simply open a new Opera browser window and leave the application. This will prevent many applications relying on the WebBrowser control from working.

A workaround is to set back IE as the default web browser by modifying registry key, see this. Another workaround is not to use the extension “.htm” or “.html” when calling .Navigate(). For example, instead of




The document contents will still be rendered properly despite the “.tmp” extension. This trick, however, does not help if you want to the web browser to navigate to an external URL, e.g.

Also, on many devices, the WebBrowser.Navigating event never fires, which I could not find a workaround for it.

3. Local images not rendered when DocumentText is set. This may seem a trivial problem with image path or format, but it’s actually not. The problem is particular to .NET Compact Framework 3.5 running on Windows Mobile 6.5. The web browser control will refuse to render any local images and only display placeholder if the HTML is set via the DocumentText properly. Strangely it will display remote images from a web server. Images are also displayed correctly if the DocumentText is written to a file and loaded by calling Navigate(). The problem never appears on older .NET Compact Framework or Windows Mobile versions.

All the above seemingly trivial problems are just making life harder for the Windows Mobile developers.

0.00 avg. rating (0% score) - 0 votes


A tough developer who likes to work on just about anything, from software development to electronics, and share his knowledge with the rest of the world.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>