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:
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. http://www.google.com.
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.