Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search

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.
[7/19/2014]

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:

IE9Browser  

Web Browser control in a WPF form:

WebBrowserControlWpfForm

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:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION

Value Key: DWORD - YourApplication.exe

32 bit on 64 bit machine:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION

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:

RegistryEditorEmulation

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;

    MessageBox.Show(doc.body.outerHtml);
}

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

<BODY><DIV> 
<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> 
<FIELDSET><LEGEND>Box with Header</LEGEND> 
<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=" "> 
<HR> 
<INPUT id=btnLogin value=Login type=button> </DIV> 
<DIV class=dialog-statusbar>Ready</DIV></DIV></FIELDSET> </DIV> 
<SCRIPT type=text/javascript> 
    $(document).ready(function () { 
        $("#divDialog") 
            .draggable({ handle: ".dialog-header" }) 
            .closable({ handle: ".dialog-header", 
                closeHandler: function () { 
                    alert("Window about to be closed."); 
                    return true;  // true closes - false leaves open 
                } 
            }); 
    }); 
</SCRIPT> 
</DIV></BODY>

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:

<body>
    <div>

        <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: 2px solid steelblue; width: 550px;" class="roundbox boxshadow">
                    <div style="background: khaki;" class="boxcontenttext roundbox">
                        Simple Rounded Corner Box.
                    </div>
                </div>
            </fieldset>

            <fieldset>
                <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.
                    </div>
                </div>
            </fieldset>



            <fieldset>
                <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>
                    <div class="descriptionheader">This dialog is draggable and closable</div>
                    <div class="dialog-content">

                        <label>Username:</label>
                        <input name="txtUsername" value=" " type="text">

                        <label>Password</label>
                        <input name="txtPassword" value=" " type="text">

                        <hr />

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

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

            </fieldset>

        </div>


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

    </div>
</body>

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:

Setup6432

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…

Summary

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.

Make Donation
Donate Bitcoins
Posted in .NET  FoxPro  Windows  

The Voices of Reason


 

Vish
May 24, 2011

# re: Web Browser Control – Specifying the IE Version

Nice! Very useful and timely for me :) One question I had that I thought you might be able to help with was whether application configuration is done only name. So, if there are multiple apps with the same name on the machine, all of em are forced to use the same IE settings?

Thank You,
Vish

Rick Strahl
May 24, 2011

# re: Web Browser Control – Specifying the IE Version

@Vish - yes it looks like the feature emulation is tied to the EXE name so if you have multiple copies they all use the same settings. But that begs the question. Why on earth would you want to have multiple settings for the same application (other than possibly a runtime/development environment of some sort)?

Mark
June 19, 2011

# re: Web Browser Control – Specifying the IE Version

Rick,

Excellent post - many thanks.

It is a little hard to understand why the WebBrowser control does not default to using the highest version of IE installed but I suspect people much brighter than I have a defensible reason.

Kind Regards
Mark

Rick Strahl
June 20, 2011

# re: Web Browser Control – Specifying the IE Version

@Mark - I think it's for backwards compatibility. IE 9 actually has many MSHTML object model changes that would likely break old applications. One I've run into is that the Range objects in IE 9 use the standards based Range object as opposed to text/control ranges in the past. I recently switched an app over to IE9 operation and that broke a ton of functionality which I had to work around with client side script code called from the host application. It took a lot of experimenting to get this right because it now has to work with both old and new versions of IE (testing is a lot of fun for this).

By specifying the version in the registry you tie an application to a specific version (although you still have to deal with downlevel support for older browser installs - yuk).

Incidentally this version switching scheme is an excellent way to let you test operation under various versions of IE :-) You can have an app hosted in the Web Browser control and manually (or via code) switch the registry values to use a different version of IE.

G. Andrew Duthie
June 23, 2011

# re: Web Browser Control – Specifying the IE Version

Awesome, Rick! This was just what I needed. Putting together something for a demo, and your post just saved me a ton of work.

Thanks!

Andrew

Richard
September 14, 2011

# re: Web Browser Control – Specifying the IE Version

It's a shame they can't use the X-UA-Compatible header/meta-tag to determine the rendering engine. If the page specifies "IE=9", it's a safe bet it's designed to work for IE9, so using the IE9 rendering mode won't break it.

There should at least be a property we can set to enable this, without having to elevate and hack the HKLM hive of the registry!

As for having multiple settings for the same exe name, what if two vendors produce applications with the same executable name? Vendor A wants their "helper.exe" to use IE9, and Vendor B wants their "helper.exe" to use IE7. With the current system, there's no way to have both applications working on the same PC at the same time.

Role
September 15, 2011

# re: Web Browser Control – Specifying the IE Version

I also ran into the CreateRange problem and could solve it by adding my process to FEATURE_USE_LEGACY_JSCRIPT. The problem is actually caused by the new Chakra JavaScript engine, and adding your process to FEATURE_USE_LEGACY_JSCRIPT causes the WebBrowser control to use the legacy JavaScript engine, which doesn't have the problems with CreateRange.

Rick Strahl
September 16, 2011

# re: Web Browser Control – Specifying the IE Version

@Richard - the problem is that IE needs to set up *before* it renders or even loads a page. Anything in the HTML document is too late to switch engines. Plus, once an IE engine is loaded it can't be changed for another page AFAIK. Then there's the issue of what's actually installed on the the machine. Obviously you can't render IE 9 style if IE 9 isn't installed ;-)

Rick Strahl
September 16, 2011

# re: Web Browser Control – Specifying the IE Version

@Role - Ah! That's good to know. Incidentally I've had a heck of a time trying to automate the new Range API even knowing that it's different. It breaks inconsistently and causes all sorts of headaches. Will give the old API a shot and see if that helps.

Richard
September 19, 2011

# re: Web Browser Control – Specifying the IE Version

@Rick - The IE9 shell manages to seamlessly switch between rendering modes based on the header or meta-tag without any problems. You can even use the developer tools to switch the browser and document modes on the fly.

All I'm saying is, we should be able to have this level of functionality within our own applications, without having to hack the registry. As it stands, Chromium is looking like the better option. :)

Rick Strahl
September 19, 2011

# re: Web Browser Control – Specifying the IE Version

@Richard - you get no argument from me that this should be easier and most importantly more transparent. But it is what it is - AFAIK this is the only way to get later than IE 7 behavior in the Web Browser control and while it's an ugly, ugly hack to have to resort to the registry its something that can be easily enough handled by an installer.

If there's another way I'd love to know about it. I would love to make this user selectable with a switch so they can determine what they see! Especially given IE 9's mungled ClearType only rendering that can't be turned off and which drives me nuts (and is the main reason I don't use IE 9).

Bernard Bout
October 21, 2011

# re: Web Browser Control – Specifying the IE Version

Hi Rick

How do you do this for VFP?

I added an entry in the registry :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION

vfp9.exe with dword = 9000

However even simple pages do not display and there are javascript errors.

If I add the meta tag :

<meta http-equiv="X-UA-Compatible" content="IE=9" >

then the page renders correctly.

So my Q is how can I test a form using HTML5 in the VFP9 ide - what is the registry setting that works?

Thanks

Anil
October 22, 2011

# re: Web Browser Control – Specifying the IE Version

Hi Rick,
Sorry to bother again. Its worked by adding my application name (vfp9.exe) but thing is fish tank is not working as smooth as its in ie9. Any specific reason ?

Rick Strahl
October 22, 2011

# re: Web Browser Control – Specifying the IE Version

@Anil - do you have events hooked up to the control? There's some overhead in the ActiveX container as it has to fire events into the container - if FoxPro code runs in response to anything in the DOM it'll likely slow the browser down quite a bit.

Rick Strahl
October 22, 2011

# re: Web Browser Control – Specifying the IE Version

@Bernard - not sure what you mean. Why would there be errors in IE9 or IE7? It sounds like IE is actually rendering in the right version, but the pages you're accessing are maybe generating errors? There are IE API changes in IE 9 that can break JavaScript code that worked in previous versions.

Make sure you set both 32 bit and 64 bit keys if you're running on Windows 7 so settings apply to both versions of IE (if you install the 64 bit version often the 32 bit version runs anyway especially via COM automation).

Also remember that VFP9.exe only works when you're running in the FoxPro environment. For your own app you have to add another key for the actual EXE name in the registry.

It's easy to check whether IE9 or classic rendering is used - go to a page that use CSS 3 features like the one I showed above:
http://www.west-wind.com/WestwindWebToolkit/samples/ajax/Html5AndCss3/RoundedCornersAndShadows.htm

Anil
October 23, 2011

# re: Web Browser Control – Specifying the IE Version

@Bernard you need to use 9999 to key to force ie9 version.
and rick i m not doing anything inside vfp just opening fishtank sample of ie9.

LambertWM
November 13, 2011

# re: Web Browser Control – Specifying the IE Version

Just wanted to say THANK YOU for posting this. I also appreciate your remark about not forgetting the to add a key for "yourapp.vshost.exe" :-)

thanks, Lambert

SebH
December 29, 2011

# re: Web Browser Control – Specifying the IE Version

Thanks for this usefull post.
But what about if using a dll instead of a .exe ?
What value should have then key ? example.dll ? example ? c:\mypath\example.dll ?

Rick Strahl
December 29, 2011

# re: Web Browser Control – Specifying the IE Version

@SebH - you can't do it by DLL, you can only register applications by the EXE. If it's in a DLL you need to specify the hosting EXE whatever that might be.

SebH
December 30, 2011

# re: Web Browser Control – Specifying the IE Version

Thanks for your quick reply Rick.
So there's no way for me :( I'm using a .net component to get screen captures of websites for my directory and it seems it uses the rendering engine of... IE6 (websnapshots from Tonec)
If one day i find how to, i'll post the answer there ;)

AshB
January 10, 2012

# re: Web Browser Control – Specifying the IE Version

Thank you, thank you, thank you!

Your post has saved me a lot of pain.

Here's why:
My html form that renders within my web browser control relies on the following button tag:

<button style="font-size:smaller" type="submit" name="buttonAction" value="AddSelectedProducts">Go</button>


My MVC controller code relies on the VALUE of the "buttonAction" parameter in order to process the request appropriately.

Here's the problem: IE 7 does not submit the actual button's value ("AddSelectedProducts") and instead submits whatever text is in between the button tags (in this case: "Go").

The correct behavior only appears in IE 8 and above. Your registry hack now forces my web browser control to act as expected and submit the correct value for the button.

This varying "button" behavior is noted at: http://www.w3schools.com/tags/att_button_value.asp (scroll down to where it says: "Definition and Usage")

Note: even though the w3schools spec states that this undesired behavior occurs prior to IE9, my tests show that it occurs prior to IE8. Thankfully so, since my clients are all Win XP users and not Win 7.

Cheers and many thanks,

AB

Phillip
February 02, 2012

# re: Web Browser Control – Specifying the IE Version

I found this:
<h1>Opt-In to High DPI Behavior for Web Browser Controls (WebOCs)</h1>
<span>In order to preserve compatibility with previously developed WebOCs, by default Internet Explorer 8 does not render the web content of WebOCs using the Internet Explorer 8 High DPI behavior, but rather uses the Internet Explorer 7 behavior, which scales up fonts specified in absolute values, such as points. To take advantage of the Internet Explorer 8 High DPI behavior in your programs, you need to use a DOCHOSTUIFLAG called DOCHOSTUIFLAG_DPI_AWARE. You use this flag by using the method GetHostInfo, which has a DOCHOSTUIINFO structure as one of its parameters. In turn, DOCHOSTUIINFO has a operator DWORD called dwFlags as one of its members, that can consist of one or more DOCHOSTUIFLAG values. You must include DOCHOSTUIFLAG_DPI_AWARE in dwFlags in order to take advantage of the Internet Explorer 8 High DPI behavior in your WebOC.</span><br /><br />
 
<span>The quick and easy way to simulate how the HTML content of your WebOCs will appear once opted -in to the High -DPI behavior is to open the equivalent HTML content (composed in an HTML file) in Internet Explorer 8, and simply check out the rendering at the equivalent zoom settings (120 DPI to 125% zoom, 144 DPI to 150% zoom). We do recommend that you test out the WebOC in actual High DPI scenarios to be completely sure the HTML content renders as you hoped.</span><br /><br />


here: http://msdn.microsoft.com/en-us/library/ie/cc849094(v=vs.85).aspx
Is there one of those flags to switch co IE8 as well?

markh
February 12, 2012

# re: Web Browser Control – Specifying the IE Version

OMG!!! Rick, you're right, this IS HUGE! I can't tell you how many hours and days i have researched and tried all sorts of things to get the webbrowser ctrl out of ie7 mode. Serveral posts I've seen hinted to it, but I couldn't find the answer anywhere. You totally blew me away when i found this post. I use the webbrowser for Editing and display extensively in my app for users to create markup which gets inserted in emails or web page content. The ie7 code with all caps tags, invalidated xhtml. And though it doesn't create self closing tags like you mentioned such as <br /> a lot of that can be cleaned up with STRTRAN() in vfp. Again, Thanks a ton Rick for posting this, and writing it so clearly too! Your posts are golden.

And Role, thanks so much for your post on the FEATURE_USE_LEGACY_JSCRIPT. That solved the createRange() issue.

markh
February 14, 2012

# Using DesignMode="On" with ie9

For me, I use Document.DesignMode="On" instead of Body.contentEditable=.t. The main reason is that if you have <input> elements that you want the user to be able to specify the default values for (by typing directly into the input's textbox), contentEditable will not update the "value" attribute of the element. For example:

<input style="width: 100px; height: 22px;" name="edtbox" value="test" size="23">

If I change the text in the <input> control from "test" to something else by typing inside the text box, IE behaves differently. With contentEditable=.t., IE *does not* update the "value" attribute of the input element. If using DesignMode="On" IE *does* update the "value" attribute. This is important for me, since it allows users to specify the default value of an input element in wysiwyg mode. (they can design documents with fill-in fields).

The only problem I am experiencing using DesignMode="On" (with a !DOCTYPE of HTML 4.01), is that the WebBrowser control *always* displays the Horizontal scrollbar regardless of the content in your document. It appears that the rightmose side of the document's content always goes underneath the Vertical scrollbar. This happens no matter how wide your control or content is. It seems to be a bug in the control. It's not recognizing the bounds of the vertical scrollbar. This does not happen in ie7 mode.

It's more of an issue if you have a block element of 100% width for example, with borders displayed. The right-most side of the block element will always display underneath the vertical scroll bar, no matter what you do. If anyone is able to resolve this, please reply.

Another reason I prefer DesignMode="On" is that you can right-click in the control and select "View Source". You can't do that with contentEditable=.t.

TIA if anyone can shed light on this probable bug.

markh
February 14, 2012

# DOCTYPE of HTML 4.01 or higher issues with WB ctrl

When I use the WebBrowser control to edit a document that has Doctype set to:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
there's an issue when resizing block elements.

If I resize a block element (Div, Input, etc) by dragging the handles of one dimension (width or height), it "always" increases the other dimension also. I can't figure why. It does not matter if I have the registry hack for vfp9.exe set to 9999 in BROWSER_EMULATION or not. Simply the Doctype seems to be causing this. And it doesn't matter if I'm using contentEditable=.t. or DesignMode="On". If I remove the Doctype declaration it doesn't have this issue but of course reverts back to ugly html. I guess the WB control is problematic for editing when specifying a Doctype, regardless if the hack is set for ie9 or not. Anyone else expreriencing this.

Bryan
February 15, 2012

# re: Web Browser Control – Specifying the IE Version

This site appears to be only place on the web that contains this information. Because of you, I was able to solve a client problem within 15 minutes and the customer was happy.

Rick - you da man! Thank you for posting this!

David
February 19, 2012

# re: Web Browser Control – Specifying the IE Version

Rick,
Thank you for the info. I have a 64 bit Windows 7 machine that does not have the "Wow6432Node" key, so I used the 32bit path and it worked like a charm. Could there be something else that is causing you to use the "Wow6432Node" key? Possibly an enterprise version of Windows?

Also, there appears to be a meta tag, <meta http-equiv="X-UA-Compatible" content="IE=edge">, that can be placed in the webpage itself that is supposed to force the control to use the latest version of ie for the rendering. I haven't tried it, and can't find the page again in msdn.com :(. but thought you would like to know.

Rick Strahl
February 19, 2012

# re: Web Browser Control – Specifying the IE Version

@David - I suspect you're not actually running a 64 bit version of Windows. The wow6432Node key is where the registry is redirected to by 32 bit applications so it has to be there on a 64 bit machine that has any 32 bit apps running (and it will - even Windows natively has many 32 bit apps).

I tried the meta header, but that only affects the rendering style once the browser is loaded. For me that alone didn't work.

Ken
March 21, 2012

# re: Web Browser Control – Specifying the IE Version

Rick, Thanks - it works as you said. Question is it possible to force a 64 bit wpf app to only use the 32 bit browser with a similar reg edit? My issue is pdf's - they open correctly in a 32 bit wpf app but when running 64 they need to open a new IE browser. Thanks again

Asdf
April 20, 2012

# re: Web Browser Control – Specifying the IE Version

>> what happens when setting 9000 with IE 8 installed?
>> What happens when setting 0 with IE 8 installed?

Here is my test results for user-agent value, Im using Delphi app (32bit) and IE WebBrowser ocx.

WinXP (32bit), IE8.0.6001.18702, testapp.exe (32bit)
regval 9000 = Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)
regval 0 = same user-agent as 9000 value

Win7 (64bit), IE9.0.8112.16421, testapp.exe (32bit)
regval 9000 = Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
regval 0 = same user-agent as 9000 value

I am going to use regval 0 for all application deployments, it switches to the any highest mode available in a users machine. Application can automatically update HKEY_CURRENT_USER registry tree for itself avoiding any privilege issues.

kobik
May 16, 2012

# re: Web Browser Control – Specifying the IE Version

@Rick, very good post! Thanks.

The main problem I'm trying to solve, is how to SWITCH modes at run-time (like IE developer tools does).

My application itself (not the installer) updates the registry as done by @Asdf (since I write to HKCU there is no UAC issue). I'm also using Delphi btw.

But the problem is how to refresh/reload the WB control and tell it that the registry setting were changed... It seems that the key value is read by the FIRST instance of the WB control that was created by the application. so even, If you destroy the control, change reg value , and create a new instance, the old value is preserved until you restart your application.

Maybe there is an Exec command for this, or a special message?

Any ideas?

Rick Strahl
May 16, 2012

# re: Web Browser Control – Specifying the IE Version

@kobik - I haven't figured out a way to do this at runtime. I suppose it is possible since the IE Tools let you switch the engine on the fly but I have no idea how that can be done. As far as I can tell the values are read only when the engine is created in an app for the first time.

lampson
June 10, 2012

# re: Web Browser Control – Specifying the IE Version

Hi ricky,

that is just what I want. It works and save a lot of time for me.

Thx a lot.

Jeff Rhodes
July 27, 2012

# re: Web Browser Control – Specifying the IE Version

Just wanted to say how useful this page was for me. I was tripped up by the fact that the key did not seem to be working because I was running in Visual Studio. Your <appName>.vshost.exe advice worked perfectly. Your site has been helpful to me multiple times. Keep up the good work!

E.R. Gilmore
August 21, 2012

# re: Web Browser Control – Specifying the IE Version

I have some jQuery in a page that I'm trying to hit from an activex browser control. It works fine in a regular browser but not the activex. The problem is that the activex is not in my application, so I can't change the Registry values.

Rick Strahl
August 21, 2012

# re: Web Browser Control – Specifying the IE Version

@ER - you should set those registry values when the app is installed using an installer. That's the only way I've found that to work.

Jim Tollan
September 04, 2012

# re: Web Browser Control – Specifying the IE Version

Hi rick,

thanks for many informative articles over the years, in particular really enjoyed working with your RazorHosting Engine - excellent.

Ok, back to the subject. I've in the past gone with adding:

<meta http-equiv="X-UA-Compatible" content="IE=9" >


I've also made sure that the doctype is:

<!DOCTYPE html>


with the caveat that IE9 has to be installed on the host machine. this has been mainly fine for me as this has been used mainly on intranets where the environment is known, or in conjunction with your RazorHosting engine.

Thanks again
jim

Rick Strahl
September 04, 2012

# re: Web Browser Control – Specifying the IE Version

@Markh - to remove the scroll bar you can set: html,body { overflow:none }. You can also explicitly reference the document and set the scroll style to none from code.

zxMarce
September 13, 2012

# re: Web Browser Control – Specifying the IE Version

Rick,

I can confirm that under WinXP with IE8, a DWORD value of 0 (zero) will pick IE8, thus seeming to confirm your "invalid value determines default browser" theory.

Only tested on one machine. YMMV.

shane
October 02, 2012

# re: Web Browser Control – Specifying the IE Version

Thanks god it works like a champ. I've been searching for this for years and finally found it here. God bless you, Rick, God bless you !

JD
November 10, 2012

# re: Web Browser Control – Specifying the IE Version

Thanks man! I've been searching for this for months!! FINALLY found it here. Been working on a project to parse email from Yahoo... but the Yahoo Email App would never display properly so I couldn't emulate clicks properly. Very helpful with automation!!!

John Kortis
November 22, 2012

# re: Web Browser Control – Specifying the IE Version

Thanks for this, it has been a wonderful help. Quetsion though, Crystal Reports renders larger in the COntrol than in the browser, even with the settings.... any thoughts

simon
December 10, 2012

# re: Web Browser Control – Specifying the IE Version

again MS stuff up with this pathetic override. What sense does it make to add the "application name" for the exe, when there could be multiple different applications with the same EXE name. there is no global identifier for apps to prevent users installing same named exe's, but MS couldn't think logically yet again. Why not just put the EXE's full path in the registry? I don't know, maybe that makes too much sense? This override has the potential to really stuff up other vendors apps when setting for your own exe.

Rick Strahl
December 11, 2012

# re: Web Browser Control – Specifying the IE Version

@Simon - I guess this means you should make sure your application uses a good solid unique name :-) There are serious issues with this whole affair for sure, but naming conflicts are probably the least of the problems you have to worry about.

Rich
December 14, 2012

# re: Web Browser Control – Specifying the IE Version

Thanks for this, very helpful! Just one question: is the 7000 (IE7) mode the same as the default webbrowser control setting (= no registry entry)? If not, what's the difference?

Thanks!

Rick Strahl
December 14, 2012

# re: Web Browser Control – Specifying the IE Version

@Rich - yes it would appear that's the default setting.

Icey
December 20, 2012

# re: Web Browser Control – Specifying the IE Version

Hello! But in my application, it seems not work at all.

My Environment: VS 2010 C#, .NET 4, local IE8.

Below is my code.
In my app, java script errors dialog always be popupped, even the register key is set. But in IE8, the 2 URLs works well.

using System;
using System.Collections;
using System.Collections.Generic;
using System.Diagnostics;
using System.Drawing;
using System.IO;
using System.Runtime.InteropServices;
using System.Text;
using System.Text.RegularExpressions;
using System.Threading;
using System.Windows.Forms;
using Microsoft.Win32;
 
 
namespace ol
{
    public partial class Form1 : Form
    {
 
        public Form1()
        {
            InitializeComponent();
 
            //RegWebBrowserIn32BitIE8Mode();
        }
 
 
        private void RegWebBrowserIn32BitIE8Mode()
        {
            RegistryKey key = Registry.LocalMachine.CreateSubKey(@"SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION");
            key.SetValue(Path.GetFileName(Application.ExecutablePath), 0, RegistryValueKind.DWord);
            key.Close();
        }
 
 
        private void button1_Click(object sender, EventArgs e)
        {
            webBrowser1.Navigate("http://pan.baidu.com/share/link?shareid=94975&uk=673798325");     //URL1
            //webBrowser1.Navigate("http://dl.dbank.com/c0wtze2ttu");                               //URL2
        }
        
    }
}

Rick Strahl
December 20, 2012

# re: Web Browser Control – Specifying the IE Version

@Icey - this is a terrible idea. For one thing most applications won't have rights to write the registry key and that's most likely what's happening.

If you're going to muck with this - do it during the application installation, or else you have to ensure you run with elevated rights (ie. Run As Administrator).

Icey
December 20, 2012

# re: Web Browser Control – Specifying the IE Version

Thanks.

The code is just a sample to test.
I tryed adding the register key out of my application, in another word, I added the register key by REGEDIT application, and then ran my app, my app still had problem. The account is Administrator account.

Rick Strahl
December 21, 2012

# re: Web Browser Control – Specifying the IE Version

@Icey - All I can tell you is that this works for every application I've tried. Just make sure you write the right keys and in the right place in the registry for 64 bit and 32 bit applications. On 64 bit systems you have to write it into both places as 32 bit applications will look in one place and the 64 bit ones in the other.

Vibhore Tanwer
January 06, 2013

# re: Web Browser Control – Specifying the IE Version

Hi, These settings are not working on Windows 8 64 bit version but works fine on Windows 8 32 bit version. Any help why that could be happening?

Rick Strahl
January 06, 2013

# re: Web Browser Control – Specifying the IE Version

Are you setting both the 32 bit and 64 bit keys? You need to set both since on a 64 bit machine both are used. 32 bit apps use the 32 bit version of the Web Browser control, 64 bit apps use the 64 bit one.

Vibhore Tanwer
January 18, 2013

# re: Web Browser Control – Specifying the IE Version

Yes, I am setting both the keys, my application is 32 bit WPF application and these settings works well on 32 bit version of Windows but not on 64 bit version of Windows. It fails on both Windows 7 64-bit and Windows 8 64-bit. Is there anything else that I am missing?

paul
January 22, 2013

# re: Web Browser Control – Specifying the IE Version

Hey thanks... was looking everywhere for exactly this but happened to stumble on it almost by chance (or is it simply that we are generally not enough aware of all that is going on) :)

Dmitri
February 14, 2013

# re: Web Browser Control – Specifying the IE Version

as pointed out above, can't get it to work on Win 8 64 bit. same wpf app works on Win7 64 bit. both 32 and 64 bits keys are set. Has anyone been able to get it to work on Win8?

Rick Strahl
February 15, 2013

# re: Web Browser Control – Specifying the IE Version

@Dmitry - hmm... works for me. Both 32 bit and 64 bit compiled versions of my EXE work and show rounded borders and shadows.

Make sure you're explicitly running the EXE and not out of the Visual Studio debugger because the debugger actually uses a different hosting EXE! Also make sure the name matches exactly in the registry and you're using the right kind of value (DWORD).

Note too that on Windows 8 you can use 10000 for IE 10.

Dmitri
February 15, 2013

# re: Web Browser Control – Specifying the IE Version

Thanks Rick! I tried different combinations of x86 and 64 bit still no luck. I made sure to run the right exe. I actually develop on a win7 comp and then copy to a win8 machine. strange.

Dave
March 15, 2013

# re: Web Browser Control – Specifying the IE Version

Hi, I am having the same problem with Win8 64bit and VS2012. This solution is not working. Browser keeps saying IE7. Very frustrating. The application is specifically for a kiosk, so I suppose I could always install 32bit. Anyone manage to figure this out?

Paco
April 05, 2013

# re: Web Browser Control – Specifying the IE Version


Rick:

Thanks to you, I got it to work on Win 8 with IE10. ( No luck on Win 7 with IE9.)

But.. (always a but).. I have a Windows Form application using a webbrowser control to automate navigation through a web site. At one point, I must click on calendar control that causes navigation to another page. In a free standing browser (IE9 or IE10) clicking a day on the calendar causes immediate navigation to the desired page with virtually no delay, but in the webbrowser control, clicking a day causes a call to the server and postback with substantial delay before switching pages. The html for the calendar days uses j-stuff that I really don't understand, and don't know how to trigger.

Any ideas would be greatly appreciated.

Paco

Paco
April 06, 2013

# re: Web Browser Control – Specifying the IE Version

Rick:

The short version of my previous comment is this..

Even with IE 10 in my webbrowser control, handling of jscripts or jquerys is different than in a free standing browser.

Can you shed any light on this?

Paco

Tom Py
April 19, 2013

# re: Web Browser Control – Specifying the IE Version

Thanks SO much. I just started getting script errors this year in an app I wrote years ago that actually stopped loading data from site when it got the error. With this fix, which I did not see anywhere else through Google, my app loads the flash data properly.
I'm using ie10 in windows 7 and 270f hex worked for me.
Thanks!

Rainer Euhus
May 17, 2013

# re: Web Browser Control – Specifying the IE Version

Hi Rick,

Thank you for the information.

Solved a problem with a 'position: fixed' element, which wasn't displayed before I added the registry entry.

Jon Alonso
June 17, 2013

# re: Web Browser Control – Specifying the IE Version

Thank you for the article! I found it more than useful. I was struggling with the CSS differences between my IE8 and the embedded browser, but changing the latter to IE8 mode just solved the problem.

Drew White
July 27, 2013

# re: Web Browser Control – Specifying the IE Version

The answer was in here - but for me proved simpler than any of the full resolutions suggested. Since I personally only needed to display HTML that I was generating in that window, I found that by adding:

<meta http-equiv="X-UA-Compatible" content="IE=10" >

..that was enough to get all my HTML5 funcionality working - no reg tweak needed (of course IE10 is needed on the machine running the VB6 exe)

Plasbot
August 28, 2013

# re: Web Browser Control – Specifying the IE Version

A thousand thanks to you friend!
I was agonizing over a problem and finally gave up with webbrowser, and was looking for an alternative on stackoverflow when I stumbled across a comment about "feature mode emulation", and suddenly I realized that was my problem. I was simply trying to make a webbrowser login to tumblr. I couldn't even get it to work typing it and clicking myself.
Thought the problem was something to do with: oAuth, tokens, cookies, https not working when ScriptErrorsSuppressed = True, and several other things but it never occurred to me that my VS2012 on Windows 8 was running IE in IE6 mode! Jeez!

Per
September 02, 2013

# re: Web Browser Control – Specifying the IE Version

Hi Rick, I really have a strange issue here and hope you can help.

I was making a new Windows Forms app which make use of WebBrowser control.
(I run this app elevated, as I do some other things with IIS and need admin rights)

When I try to add my executable to both HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION registry keys, it only gets registered at the Wow6432Node key?

But if I programmatically check if key exists, it says both are there?

Even if I force to write to both places it still, when you look manually, appears only at Wow6432Node but when check with the program it says it exists in both places??

Per
September 02, 2013

# re: Web Browser Control – Specifying the IE Version

Hi again Rick.

Found answer, when executable is compiled targeting x64 it writes to both registry keys, but when it is compiled to 'any' or x86, it only writes to the Wow6432Node key.

Sandra
September 12, 2013

# re: Web Browser Control – Specifying the IE Version

Hi Rick,

Thank you so much for this article!

I am however experiencing problems and was wondering if I am doing something wrong or it is caused because it is not 100% IE9. I have updated the registery in both places, and put <!DOCTYPE html> and <meta http-equiv="X-UA Compatible" content="IE=9" /> on my page. I have set registry entry value to 9000.

I am experiencing several problems, below is a short list.

I found that the tag <section> is completely ignored, if you set css setting on it, like background-color, it doesn't work.

Another problem is with javascript, the Array.prototype.map() function just gives an error.

I hope you can help me out. Thanks in advance!

Sandra

Carlos Cuesta
October 25, 2013

# re: Web Browser Control – Specifying the IE Version

Hi Rick,

Thanks, thanks, thanks....

I was frustrated trying WebBrowser control work in a multiple year development product.
You saved me many months for change the control with another one, and tons of work.

Thanks so much,
Carlos

markh
November 26, 2013

# re: Web Browser Control – Specifying the IE Version

Just FYI, in case anyone's having issues with IE11 and the webbrowser control...

With IE11 now installed i've had to change my value from 8000 to 8888. I was getting OLE errors in IE11 when doing createRange() and trying to access the nodeName or tagName of the parentElement. Changing the value to 8888 solved it. I don't use 9000 or 9999 or higher, since i need to make sure my webbrowser control works in IE8 still. I use the webbrowser control as an Html editor also.

Also, Microsoft has updated the list of valid values to add IE10 and IE11 at the website link Rick provided in the article above.

Again, Rick this article has been enormously helpful. Many Mahalo's!

Rick Strahl
November 26, 2013

# re: Web Browser Control – Specifying the IE Version

@Markh - the createRange() problem has been a problem for a while dating back to IE 9 and standards mode. Starting with IE 9 IE is using use DOM compliant range functions rather than the old IE based ones (which were far easier to use). Basically you have to decide which version to use and make sure that you use the right functions for that version. The 8888 forces IE 8 mode explicitly so you're staying on your compatibility mode, but won't get the newer rendering features of IE 11.

sellenoff
March 18, 2014

# re: Web Browser Control – Specifying the IE Version

Great post Rick. Been searching for awhile to solve this!

Oddly, I'm seeing behavior that nobody has described here. While the rounded corners render as they should, the buttons do not render the same as they do in the stand alone IE.

I've got a simple VFP9 app hosting the IE control and it loads up your demo page:
http://www.west-wind.com/WestwindWebToolkit/samples/ajax/Html5AndCss3/RoundedCornersAndShadows.htm

While the rounded corners work once the Reg Hack is in place, the login button does not render the same as it does in the hosted ie control. I'm on 64bit windows 7 with IE9. Does it work for you? Any suggestions what's causing this odd behavior?

Much appreciated-
Steve

Denny
May 08, 2014

# re: Web Browser Control – Specifying the IE Version

Hi Rick, great post...
...but what i have to do if my application is an asp.net page?
I'm using the webbrowser control in a server page ( Razor, but it's not the point ) to capture the screnshot of a given url and save it to disk.
What application ( .exe ? ) i have to specify in the registry key?

Could you help me?

Thank you in advance :-)

Rick Strahl
May 08, 2014

# re: Web Browser Control – Specifying the IE Version

@Denny - wow really? :-) I hope that's an internal thing you're doing... Anyway the process would be Internet Explorer or iExplore.exe I think.

Steve
May 10, 2014

# re: Web Browser Control – Specifying the IE Version

Very nice. Thanks. Any thoughts on updating keys when a ClickOnce app is used?

Olivier
May 21, 2014

# re: Web Browser Control – Specifying the IE Version

Thank you for this very useful informations.

I can confirm that with Win7/IE11, using dword value '0' for the registry key of your app will default to the installed browser version

iceuponfier
June 06, 2014

# re: Web Browser Control – Specifying the IE Version

Thanks you very much everyone for the infos about the dword value "0", it's help a lot!!!! By the way the microsoft documentation explain you can also push this configuration into the HKEY_CURRENT_USER key :)

Todd Morrow
June 24, 2014

# re: Web Browser Control – Specifying the IE Version

Hi Rick,

I'm trying to have a single winforms application with a tab control that displays a different IE version in each tab. Yep at the same time.

If I could "fake" the application name depending on what tab I was on that would do the trick.

When IE control goes to load a page, I'm sure it checks the registry with the name of the exe that it finds itself in, correct? So I want to hack / fool that API call.

Todd Morrow
June 24, 2014

# re: Web Browser Control – Specifying the IE Version

ok let me answer my own question...

yes, this is possible, by hosting multiple exe's in the main exe.

http://www.codeproject.com/Articles/9123/Hosting-EXE-Applications-in-a-WinForm-project

Marc
July 15, 2014

# re: Web Browser Control – Specifying the IE Version

Two of the values for IE10 and IE11 are incorrect in your table (you had 11999, 11000, 10999 and 10000). According to the MS documentation you link to:

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

11000 (0x2AF8) IE11. Webpages containing standards-based !DOCTYPE directives are displayed in IE11 edge mode. Default value for IE11.

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

10000 (0x02710) Internet Explorer 10. Webpages containing standards-based !DOCTYPE directives are displayed in IE10 Standards mode. Default value for Internet Explorer 10.

Furthermore, you can do this at runtime by writing to HKCU\Software\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION, so long as you write your executable name in before instantiating any web browser controls. When writing to HKCU, you (a) don't need elevated privileges, and (b) don't have to worry about 32 vs 64 bit -- the wow6432node key is not used in HKCU.

Joe De Ville
September 26, 2014

# re: Web Browser Control – Specifying the IE Version

Rick,

Really appreciate all the tips and info over the years. This tip in particular has helped me with an issue that's plagued me for the last several years.

My application of the webbrowser control is not nearly as sophisticated as many of the posters here, but once I edited the registry, I was able to get correct rendering and other behavior in IE 11.

I do still have a problem, though.

The InnerText property of the document now contains (or at least now returns) HTML along with the text, where previously I was able to capture only the text.

Do you know of a simple way to extract only the text (i.e. remove any superfluous HTML?

Thanks for any help.

Joe

Rick Strahl
September 26, 2014

# re: Web Browser Control – Specifying the IE Version

@Joe - .innerText should always return text not HTML. If it's returning HTML you like had encoded HTML text in the element in the first place. Maybe the assignment was incorrect (ie. assigning HTML to .innerText).

Joe De Ville
September 26, 2014

# re: Web Browser Control – Specifying the IE Version

Ahh! I see what I did now. It's javascript embedded in the content I used as a template.

Operator error, as usual. :-)

Thanks!

Joe

Theodoros Flabouras
December 20, 2014

# re: Web Browser Control – Specifying the IE Version

@Bernard: Thanks for this :<meta http-equiv="X-UA-Compatible" content="IE=9" > suggestion!

I was doing some tests with d3.js in web browser control inside a vfp form, and was getting script errors.

Many many thanks to Rick as well, you're a real gem!

Grant Edwards
February 03, 2015

# re: Web Browser Control – Specifying the IE Version

Brilliant!

After spending a couple weeks working on the web pages in an embedded device, I was pretty happy with the results -- I had even added some extra code to get things to work as far back as IE8 (which is as far back as we're willing to support). Then I fired up a windows app that ships with the device and contains an embedded IE control. Of course, it looked like a disaster. For a while, I thought I was going to have to start all over again. Then Google let me to your blog, and my problem vanished.

Many thanks...

Hilaly Hassan
February 14, 2015

# re: Web Browser Control – Specifying the IE Version

i tried to use embed web browser control to execute an css web menu under win xp + IE8 but in vain even though i modified the registry key as shown

I added this DWORD Key :
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

with :
key name = vfp9.exe Decimal value = 8000

But nothing happends.
note : this css menu works well inder win7+IE11

Needs helps
thinks

Govindarajan
March 11, 2015

# re: Web Browser Control – Specifying the IE Version

Hi Guys,
I'm running a windows service to render a HTML content on WebBrowserCotrol and take the screenShot of the output and save it in the specified local directory. I'm able to achieve this if i'm logged in the server, if I'm logged out of the server I'm getting the script error. I think it still try to find the registry entry in the HKEY_CURRENT_USER

I have tried all the below option

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BROWSER_EMULATION

Any idea on this?

Regards,
Govind

Ken
May 21, 2015

# re: Web Browser Control – Specifying the IE Version

Hi

This entry has been incredibly useful in resolving some issues I've been having with using the browser control under Win7 and IE11. I've played with all the indicated values and find 270F, 2AF9, 2711 work the best so far. Outstanding is that somewhere deep in the bowels I get a dialog box "Message from webpage" "Client side XSL transformations are not supported on your browser". The message does not occur from a desktop browser. I've done a few searches and can't find anything to help. Would you have any pointers on how to resolve this?

Thanks
Ken

RM
July 13, 2015

# re: Web Browser Control – Specifying the IE Version

Hi Rick,

I have added Registry key to HKEY_CURRENT_USER and Wow6432Node folder and script error problem is resolved. Thanks a lot for this nice post.

But now HTML is not rendering properly. Any specific reason? This is a production issue and need to be fixed ASAP. DocType is XHTML 1.0 Transitional.

Ken
July 28, 2015

# re: Web Browser Control – Specifying the IE Version

Hi

I've played with various settings but still end up with some problems. The application targeting runs fine in a desktop browser that has the enterprise mode set on. Is there some way I can set Enterprise mode for what runs in the library

Thanks
Ken

Web Browser Control – Specifying the IE Version
August 09, 2015

# re: Web Browser Control – Specifying the IE Version

Hi,

Great Post..Thanks a lot...

But small issue......

I created a new class to specify the IE version in registry as Machine or Current User.But first time my application not working,second time its working fine...Any update or refresh command required for Webbrowser Control.

Rick Strahl
August 10, 2015

# re: Web Browser Control – Specifying the IE Version

Did you restart? The change has to be made before the app is started or else the registry change is not read.

Robert Muehsig
September 15, 2015

# re: Web Browser Control – Specifying the IE Version

On Windows 10 it seems easier to skew things up. If you choose a "unkown" IE Version (e.g. 0) or anything else you will just see a blank page and an endless process will run.

I ended up with these settings which seems to work with Win10 and use the latest IE11 engine:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"App.exe"=dword:00002af9
"App.vshost.exe"=dword:00002af9

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"App.exe"=dword:00002af9
"App.vshost.exe"=dword:00002af9

Thanks also to this blogpost here: https://kevinragsdale.net/windows-10-and-the-web-browser-control/

Nathan
October 11, 2015

# re: Web Browser Control – Specifying the IE Version

Awesome fix to adjust rendering for Webbrowser WPF Control. This helped me be able to display graphing in the WPF control using the Javascript package Flot.

Akabrando
October 13, 2015

# re: Web Browser Control – Specifying the IE Version

Thank you so much.
The registry hacks just solved my problem.
I have answered myself question on stackoverflow with reference to this page.
http://stackoverflow.com/questions/33098335/only-white-color-with-zoom-control-shown-in-google-maps-div-area/33108011#33108011

Matt
November 17, 2015

# re: Web Browser Control – Specifying the IE Version

Anyone have luck implementing this registry update for running the Web Browser dev tool within Powerpoint? I'm not entirely sure what application I should be writing this hack to... Any help would be greatly appreciated!

Pavel
February 05, 2016

# re: Web Browser Control – Specifying the IE Version

Hello again,
I'd like to review the statement. Using wb.Navitage("http://someurl...") works fine for 9000 as well. And there are all linebreaks for 11000.

How do I achive the same for wb.Navigate("about:blank") and wb.Document.Write(<!DOCTYPE><html><head></head><body>" & txtText.Text & "</body></html>") ? It seems that the document mode is not loaded properly in this scenario.

Rick Strahl
February 05, 2016

# re: Web Browser Control – Specifying the IE Version

@Matt - POWERPNT.EXE

@Pavel - if you need to load a full page I recommend you write a file to disk then navigate to disk. You can then apply the appropriate DOCTYPE to the document that's on disk.

Pavel
February 07, 2016

# re: Web Browser Control – Specifying the IE Version

@Rick, I'd like to avoid using files. But your suggestion pointed me to the "navigate to correct document" solution.

about:blank is the problem! Using different about:xxxxxxx causes the document to load in different mode.
about:navigationcanceled as initial navigation worked fine for me.

Thank you

Rick Strahl
February 08, 2016

# re: Web Browser Control – Specifying the IE Version

@Pavel - Navigating to file is the best thing you can do actually because there's an actual document there to start with. As you found out about:blank isn't a real HTML document so you can't really modify it. And you do want to navigate so you can load a complete HTML document including doc type and docheader so you have full control over the HTML rendered. That's what I do in my offline apps that use Web Browser. Additionally this is nice because you have a debug trail - you can open the doc in a different browser and use debug tools if you need to (which you can't do in the Web browser control).

Leandro Duarte
February 14, 2016

# re: Web Browser Control – Specifying the IE Version

Thank you so mutch

Tristano Ajmone
April 12, 2016

# re: Web Browser Control – Specifying the IE Version

GREAT ARTICLE! It was very useful...

Just one CORRECTION:

You mentioned the registry key value "11001 (0x2EDF)", but it should be "11001 (0x2AF9)" instead!

I stumbled on this error while testing this feature inside an app using WebBrowser Control — decimal and hex didn't add up, so I realized it was a typo.

It really works smoothly. Before this hack, I could only use IE4 HTML4 in my apps using the WebBrowser Control... but tweaking the registry as adviced here, resulted in HTML5 + CSS3 pages showing up nicely inside the WebBrowser Control!

I guess the hard part will be to now carry out all the research in order to make sure the app checks out which version of IE is present on the system. There are legion of hacks (from HTML comments to JavaScript) to do that, but most of them are intended for the web. In the context of compiled applications, the checks should be restricted to IE only. If I find a clean solution I'll paste some links/examples here...

Ryanba29
April 18, 2016

# re: Web Browser Control – Specifying the IE Version

In c# at least you can specify System.AppDomain.CurrentDomain.FriendlyName.ToString() in place of the executable name. That way you don't have to change your executable name for debug mode.

James
May 05, 2016

# re: Web Browser Control – Specifying the IE Version

Thank you for this informative explanation.

I am new to desktop application development and I have few questions on this topic that I hope you would be able to clarify for me. I am trying to create a simple web browser, no address bar and when the application is opened, it opens directly to a webpage I hardcoded. I am receiving javascript errors and display issues when the page is opened in the application , but not when I open the page in my IE 11 browser. I am assuming its the webbrowser using the old engine that is causing the problem?

1. In Microsoft Visual Studio Community 2015, does the WebBrower still use the IE 7 engine?
2. Would the registry hack you suggest work across Windows 7,8, 10?
3. Wouldn't MS security prevent registry updates from an application?
4. Do you have any suggestion for a different compiler that I could embed a more modern webbrowser/engine into? This would be a Windows desktop application only. No mobile, no Apple.

Thank you for your time.

Rick Strahl
May 05, 2016

# re: Web Browser Control – Specifying the IE Version

1.) I think VS 2015 uses a later version - they are using this registry hack as well - DevEnv is one that is listed.
2.) Yes it works on all versions of Windows. The trick is making sure you get the right browser version - at this point go with 11001 always
3.) You can't update the HKLM registry unless you run as admin, but you can upload HKCU key from an application
4.) IE 11 is plenty 'modern' - it does a great job with just about all modern Web content

There are other engines like Awesomian and a few others, but frankly they are all very flakey on WIndows. I have several applications that use Awesonium on my Windows box and they are all broken on my Bootcamp'ed Mac because the Awesomium SDK is apparently broken. The IE control works fine. I have several products that rely heavily on browser automation (http://markdownmonster.west-wind.com/ and http://helpbuilder.west-wind.com) and these are working without problems with IE based browser controls.

Rick Strahl
May 05, 2016

# re: Web Browser Control – Specifying the IE Version

1.) I think VS 2015 uses a later version - they are using this registry hack as well - DevEnv is one that is listed.
2.) Yes it works on all versions of Windows. The trick is making sure you get the right browser version - at this point go with 11001 always
3.) You can't update the HKLM registry unless you run as admin, but you can upload HKCU key from an application
4.) IE 11 is plenty 'modern' - it does a great job with just about all modern Web content

There are other engines like Awesomian and a few others, but frankly they are all very flakey on WIndows. I have several applications that use Awesonium on my Windows box and they are all broken on my Bootcamp'ed Mac because the Awesomium SDK is apparently broken. The IE control works fine. I have several products that rely heavily on browser automation and these are working without problems with IE based browser controls.

Paul Murray
June 12, 2016

# re: Web Browser Control – Specifying the IE Version

Thanks Rick!!

I use PowerBuilder to create HTML pages with Google Maps Javascript which is rendered in the Microsoft Web Browser ActiveX control. It stopped working a while back. I was wading through that crazy long Google Post (9004) for hours (12) and trying everything under the sun. Nothing worked until I focused on your comments and read your blog. I changed my GM header to use v=3.24.0, installed IE 11.0 and created an entry under WOW in registry for my application.exe using hex 2AF9. Oddly, 2AF8 did not work.

Anyway, it all works now and I wanted to send my most sincere thanks for your post. Really great!!

Thanks!!

Paul

Roman
June 29, 2016

# re: Web Browser Control – Specifying the IE Version

Hello Rick,

Nice article! However, I stumbled upon a weird use case when changing the registry keys didn't really help.

I am one of the devs for a communication tool, that among other features has an option to set up Windows screensavers. Thing is, these screensavers can contain HTML content, and I really wanted to render it in modern browser, like IE11. So I went through, added required keys and words in local_machine and current_user, adding the rules for screensaver our software generates.

The result is - if I just go on and launch the screensaver manually (by executing .scr file) - it renders in emulated IE11. If I go to screensaver settings and use the "Preview" function - it renders in emulated IE11. However, when the screensaver is launched by the system itself - it still draws all the stuff using IE7.

I was wondering if you might have any insight on what else should be changed for this to work. I tried adding usual Windows scrnsave.exe utility and our application itself to the browser emulation rules list, to no avail.

Regards,
Roman