Web Browser Control – Specifying the IE Version

I use the Internet Explorer Web Browser Control in a lot of my desktop applications to display document type layout or any kind of summary text information usually. HTML happens to be one of the most common document formats and displaying data in this format – even in desktop applications, is often way easier than using labels or edit boxes or even some of the WPF text containers. HTML is easy to generate, generally re-usable and easily distributable.

One issue the Web Browser Control on Windows has that it’s perpetually stuck in IE 7 rendering mode by default. Even though IE 8 and later now have significantly upgraded the IE rendering engine to be more CSS and HTML compliant by default the Web Browser control will have none of it. IE 9 and later versions of IE with their much improved CSS support and basic HTML 5 support are a big improvement and even though the IE control uses some of IE’s internal rendering technology it’s still stuck in the old IE 7 rendering by default.

This applies whether you’re using the Web Browser control in a WPF application, a WinForms app, a FoxPro or VB classic application using the ActiveX control. Behind the scenes all these UI platforms use the COM interfaces and so you’re stuck by those same rules.

This article has been updated versions of IE later than IE 9 which was discussed in the original article. Where IE 9 is mentioned, later versions of IE (10,11) can be substituted with the same behavior for those respective versions.

Rendering Challenged

To see what I’m talking about here are two screen shots rendering an HTML 5 Doctype page that includes some CSS 3 functionality – rounded corners and border shadows – from an earlier post. One uses IE 9 as a standalone browser, and one uses a simple WPF form that includes the Web Browser control.

IE 9 Browser:


Web Browser control in a WPF form:


The IE 9 page displays this HTML correctly – you see the rounded corners and shadow displayed. Obviously the latter rendering using the Web Browser control in a WPF application is a bit lacking. Not only are the new CSS features missing but the page also renders in Internet Explorer’s quirks mode so all the margins, padding etc. behave differently by default, even though there’s a CSS reset applied on this page.

If you’re building an application that intends to use the Web Browser control for a live preview of some HTML this is clearly undesirable.

Feature Delegation via Registry Hacks

Fortunately starting with Internet Explore 8 and later there’s a fix for this problem via a registry setting. You can specify a registry key to specify which rendering mode and version of IE should be used by that application. These are not global mind you – they have to be enabled for each application individually by writing a registry value for each specific EXE that is hosting the WebBrowser control.

This setting can be made for all users on local machine registry key or per user in the current user key of the registry.

For the Current User:

I’d recommend using the current user setting, as this setting can be made in one place and doesn’t require admin rights to write to the registry. This means you can actually make this change from within your application even if you don’t use an installer or run under an Admin account.

You do have to restart the app to see the change.

The key to write to is:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

Value Key: DWORD  YourApplication.exe

Note that the FeatureControl and FEATURE_BROWSER_EMULATION keys may not exist at all prior to installation, so you may have to install that whole branch.

For all Users:

There are two different sets of keys for 32 bit and 64 bit applications.

64 bit or 32 bit only machine:


Value Key: DWORD – YourApplication.exe

32 bit on 64 bit machine:


Value Key: DWORD YourApplication.exe

The value to set this key to is (taken from MSDN here) as decimal values:regi

11001 (0x2EDF) Internet Explorer 11. Webpages are displayed in IE11 Standards mode, regardless of the !DOCTYPE directive.

11000 (0x2AF8) 

Internet Explorer 11. Webpages containing standards-based !DOCTYPE directives are displayed in IE9 mode.

10001 (0x2AF7) Internet Explorer 10. Webpages are displayed in IE10 Standards mode, regardless of the !DOCTYPE directive.

10000 (0x2710) 

Internet Explorer 10. Webpages containing standards-based !DOCTYPE directives are displayed in IE9 mode.

9999 (0x270F) Internet Explorer 9. Webpages are displayed in IE9 Standards mode, regardless of the !DOCTYPE directive.

9000 (0x2328)

Internet Explorer 9. Webpages containing standards-based !DOCTYPE directives are displayed in IE9 mode.

8888 (0x22B8) Webpages are displayed in IE8 Standards mode, regardless of the !DOCTYPE directive.

8000 (0x1F40)

Webpages containing standards-based !DOCTYPE directives are displayed in IE8 mode.

7000 (0x1B58) Webpages containing standards-based !DOCTYPE directives are displayed in IE7 Standards mode.

The added key looks something like this in the Registry Editor:


Note that the 32 bit and 64 bit settings are significant depending on the type of application you are running. If you are running a 32 bit application on a 64 bit machine you need to use the Wow6432Node key to register this setting. If you’re running a 32 bit application on a 32 bit machine, or 64 bit application on a 64 bit application, then the standard registry key should be used.  This means if you’re installing a 32 bit application using an installer you probably will want to set both the Wow64 key and the regular key on the machine.

With this in place my Html Html Help Builder application which has wwhelp.exe as its main executable now works with HTML 5 and CSS 3 documents in the same way that Internet Explorer 9 does.

Incidentally I accidentally added an ‘empty’ DWORD value of 0 to my EXE name and that worked as well giving me IE 9 rendering. Although not documented I suspect 0 (or an invalid value) will default to the installed browser. Don’t have a good way to test this but if somebody could try this with IE 8 installed that would be great:

  • What happens when setting 9000 with IE 8 installed?
  • What happens when setting 0 with IE 8 installed?

Don’t forget to add Keys for Host Environments

If you’re developing your application in Visual Studio and you run the debugger you may find that your application is still not rendering right, but if you run the actual generated EXE from Explorer or the OS command prompt it works. That’s because when you run the debugger in Visual Studio it wraps your application into a debugging host container. For this reason you might want to also add another registry key for yourapp.vshost.exe on your development machine.

If you’re developing in Visual FoxPro make sure you add a key for vfp9.exe to see the rendering adjustments in the Visual FoxPro development environment.

Cleaner HTML – no more HTML mangling!

There are a number of additional benefits to setting up rendering of the Web Browser control to the IE 9 engine (or even the IE 8 engine) beyond the obvious rendering functionality. IE 9 actually returns your HTML in something that resembles the original HTML formatting, as opposed to the IE 7 default format which mangled the original HTML content.

If you do the following in the WPF application:

private void button2_Click(object sender, RoutedEventArgs e)
    dynamic doc = this.webBrowser.Document;


you get different output depending on the rendering mode active. With the default IE 7 rendering you get this nasty mess:

<H1>Rounded Corners and Shadows - Creating Dialogs in CSS</H1> 
<DIV class=toolbarcontainer><A class=hoverbutton href="./"><IMG src="../../css/images/home.gif"> Home</A>
<A class=hoverbutton href="RoundedCornersAndShadows.htm"><IMG src="../../css/images/refresh.gif"> Refresh</A> </DIV> 
<DIV class=containercontent> 
<FIELDSET><LEGEND>Plain Box</LEGEND><!-- Simple Box with rounded corners and shadow --> 
<DIV style="BORDER-BOTTOM: steelblue 2px solid; BORDER-LEFT: steelblue 2px solid; WIDTH: 550px; BORDER-TOP: steelblue 2px solid; BORDER-RIGHT: steelblue 2px solid" class="roundbox boxshadow"> 
<DIV style="BACKGROUND: khaki" class="boxcontenttext roundbox">Simple Rounded Corner Box. </DIV></DIV></FIELDSET> 
<DIV style="BORDER-BOTTOM: steelblue 2px solid; BORDER-LEFT: steelblue 2px solid; WIDTH: 550px; BORDER-TOP: steelblue 2px solid; BORDER-RIGHT: steelblue 2px solid" class="roundbox boxshadow"> 
<DIV class="gridheaderleft roundbox-top">Box with a Header</DIV> 
<DIV style="BACKGROUND: khaki" class="boxcontenttext roundbox-bottom">Simple Rounded Corner Box. </DIV></DIV></FIELDSET> 
<FIELDSET><LEGEND>Dialog Style Window</LEGEND> 
<DIV style="POSITION: relative; WIDTH: 450px" id=divDialog class="dialog boxshadow" jQuery16107208195684204002="2"> 
<DIV style="POSITION: relative" class=dialog-header> 
<DIV class=closebox></DIV>User Sign-in 
<DIV class=closebox jQuery16107208195684204002="3"></DIV></DIV> 
<DIV class=descriptionheader>This dialog is draggable and closable</DIV> 
<DIV class=dialog-content><LABEL>Username:</LABEL> <INPUT name=txtUsername value=" "> <LABEL>Password</LABEL> <INPUT name=txtPassword value=" "> 
<INPUT id=btnLogin value=Login type=button> </DIV> 
<DIV class=dialog-statusbar>Ready</DIV></DIV></FIELDSET> </DIV> 
<SCRIPT type=text/javascript> 
    $(document).ready(function () { 
            .draggable({ handle: ".dialog-header" }) 
            .closable({ handle: ".dialog-header", 
                closeHandler: function () { 
                    alert("Window about to be closed."); 
                    return true;  // true closes - false leaves open 

IE 7 strips out all spacing, upper-cases all element names and CSS attributes and generally mangles the original HTML. Rest assured my original HTML looked nothing like this. Here’s is the IE 9 rendering mode output which looks a heck of a lot cleaner and a lot closer to my original HTML of the page I’m accessing:


        <h1>Rounded Corners and Shadows - Creating Dialogs in CSS</h1>
        <div class="toolbarcontainer">
            <a class="hoverbutton" href="./"> <img src="../../css/images/home.gif"> Home</a>
            <a class="hoverbutton" href="RoundedCornersAndShadows.htm"> <img src="../../css/images/refresh.gif"> Refresh</a>

        <div class="containercontent">

                <legend>Plain Box</legend>
                <!-- Simple Box with rounded corners and shadow -->
                <div style="border: 2px solid steelblue; width: 550px;" class="roundbox boxshadow">
                    <div style="background: khaki;" class="boxcontenttext roundbox">
                        Simple Rounded Corner Box.

                <legend>Box with Header</legend>
                <div style="border: 2px solid steelblue; width: 550px;" class="roundbox boxshadow">
                    <div class="gridheaderleft roundbox-top">Box with a Header</div>
                    <div style="background: khaki;" class="boxcontenttext roundbox-bottom">
                        Simple Rounded Corner Box.

                <legend>Dialog Style Window</legend>

                <div style="width: 450px; position: relative;" id="divDialog" class="dialog boxshadow">
                    <div style="position: relative;" class="dialog-header">
                        <div class="closebox"></div>
                        User Sign-in
                        <div class="closebox"></div>
                    <div class="descriptionheader">This dialog is draggable and closable</div>
                    <div class="dialog-content">

                        <input name="txtUsername" value=" " type="text">

                        <input name="txtPassword" value=" " type="text">

                        <hr />

                        <input id="btnLogin" value="Login" type="button">

                    <div class="dialog-statusbar">Ready</div>



        <script type="text/javascript">
            $(document).ready(function () {
                    .draggable({ handle: ".dialog-header" })
                        handle: ".dialog-header",
                        closeHandler: function () {
                            alert("Window about to be closed.");
                            return true;  // true closes - false leaves open


IOW, in IE9 rendering mode IE9 is much closer (but not identical) to the original HTML from the page on the Web that we’re reading from.

As a side note: Unfortunately, the browser feature emulation can’t be applied against the Html Help (CHM) Engine in Windows which uses the Web Browser control (or COM interfaces anyway) to render Html Help content. I tried setting up hh.exe which is the help viewer, to use IE 9 rendering but a help file generated with CSS3 features will simply show in IE 7 mode. Bummer – this would have been a nice quick fix to allow help content served from CHM files to look better.

HTML Editing leaves HTML formatting intact

In the same vane, if you do any inline HTML editing in the control by setting content to be editable, IE 9’s control does a much more reasonable job of creating usable and somewhat valid HTML. It also leaves the original content alone other than the text your are editing or adding. No longer is the HTML output stripped of excess spaces and reformatted in IEs format.

So if I do:

private void button3_Click(object sender, RoutedEventArgs e)
    dynamic doc = this.webBrowser.Document;
    doc.body.contentEditable = true;

and then make some changes to the document by typing into it using IE 9 mode, the document formatting stays intact and only the affected content is modified. The created HTML is reasonably clean (although it does lack proper XHTML formatting for things like <br/> <hr/>). This is very different from IE 7 mode which mangled the HTML as soon as the page was loaded into the control. Any editing you did stripped out all white space and lost all of your existing XHTML formatting. In IE 9 mode at least *most* of your original formatting stays intact.

This is huge! In Html Help Builder I have supported HTML editing for a long time but the HTML mangling by the Web Browser control made it very difficult to edit the HTML later. Previously IE would mangle the HTML by stripping out spaces, upper casing all tags and converting many XHTML safe tags to its HTML 3 tags. Now IE leaves most of my document alone while editing, and creates cleaner and more compliant markup (with exception of self-closing elements like BR/HR).

The end result is that I now have HTML editing in place that’s much cleaner and actually capable of being manually edited.

Caveats, Caveats, Caveats

It wouldn’t be Internet Explorer if there weren’t some major compatibility issues involved in using this various browser version interaction. The biggest thing I ran into is that there are odd differences in some of the COM interfaces and what they return.

The issue is that IE 9 and IE 10 more so, change a number of default APIs from the original Internet Explorer only DOM APIs like Selection and Events, and switch to standard HTML DOM APIs. This can cause some problems with code breaking if you’re upgrading from an old application that was using IE 7 mode. Additionally if you need to support older browsers, it can also be very tricky to manage the different versions of these APIs. The above registry keys attempt to set the browser version to the version specified but if that’s not available the browser remains stuck in the old version. This is in fact the primary reason that the Web Browser control by default is stuck in IE 7 mode – if it weren’t a lot of code, and especially a ton of Microsoft code that uses the Web Browser control would likely break.

The specific API I had issues with was the CreateRange() API which has changed to return a DOM range object, where it used to return an IE specific range object. For some reason I’m not sure off using the COM API would not return a range object – I ended up having to create the range using JavaScript and then calling into the JavaScript from the host to retrieve the range. It’s ugly but it works. Stuff like this is a pain and takes time to debug and expect this to happen if you need to support IE 8 or earlier.

Therefore I’d highly recommend that you only use this functionality if you are supporting only IE 9 and later operating systems which means anything later than XP/Windows 2003.

Registry Key Installation for your Application

It’s important to remember that the registry settings from above are made per application, so most likely this is something you want to set up with your installer. Also remember that 32 and 64 bit settings require separate settings in the registry so if you’re creating your installer you most likely will want to set both keys in the registry preemptively for your application.

I use Tarma Installer for all of my application installs and in Tarma I configure registry keys for both and set a flag to only install the latter key group in the 64 bit version:


Because this setting is application specific you have to do this for every application you install unfortunately, but this also means that you can safely configure this setting in the registry because it is after only applied to your application.

Another problem with install based installation is version detection. If IE 8 is installed I’d want 8000 for the value, if IE 9 is installed I want 9000. I can do this easily in code but in the installer this is much more difficult. I don’t have a good solution for this at the moment, but given that the app works with IE 7 mode now, IE 9 mode is just a bonus for the moment. If IE 9 is not installed and 9000 is used the default rendering will remain in use.

It sure would be nice if we could specify the IE rendering mode as a property, but I suspect the ActiveX container has to know before it loads what actual version to load up and once loaded can only load a single version of IE. This would account for this annoying application level configuration…


The registry feature emulation has been available for quite some time, but I just found out about it today and started experimenting around with it. I’m stoked to see that this is available as I’d pretty much given up in ever seeing any better rendering in the Web Browser control. Now at least my apps can take advantage of newer HTML features.

Now if we could only get better HTML Editing support somehow <snicker>… ah can’t have everything.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s