WebBrowser Control Rendering Modes in IE8
Note: The feature control key and mode information in this post is now outdated. Please refer to the updated post on this topic: https://blogs.msdn.com/ie/archive/2009/03/10/more-ie8-extensibility-improvements.aspx
Many commonly used applications and Windows system components depend on the MSIE WebBrowser control to render webpages from within their program. Unlike live sites, pages loaded within these controls are typically static resources stored in libraries and executables on a system. While webmasters can easily alter their site to render properly in the new version of IE, many software vendors do not have the resources to instantly push out new versions of their applications with updated internal pages. In order to ensure that these existing applications remain in working order, IE8 renders pages running within instances of the WebBrowser control in IE7 Standards Mode by default.
Per-Application WebBrowser Control Rendering Settings
The test container shown above uses the IE7 Standards Mode run by default within WebBrowser control containers. While this mode works well with existing applications, developers building new applications may want to use the new IE8 Standards rendering mode as shown below.
When an executable loads an instance of the WebBrowser control it scans the registry to check whether the executable wants IE7 Standards or IE8 Standards mode.
To run a WebBrowser control in IE7 Standards Mode, insert the following values into the registry:
[HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_NATIVE_DOCUMENT_MODE]
"MyApplication.exe"=dword:11170
To run in IE8 Standards Mode insert the following registry value:
[HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_NATIVE_DOCUMENT_MODE]
"MyApplication.exe"=dword:13880
In both of these instances, MyApplication.exe should be replaced with the name of the executable that will be running WebBrowser controls in a specified mode.
User-Agent String and WebBrowser Quirks Mode Rendering Issues
Specification of an IE rendering mode also applies to IE5 Quirks Mode. To run instances of a WebBrowser control in IE5 Quirks Mode, insert the following value into the registry:
[HKEY_CURRENT_USERSoftwareMicrosoftInternet ExplorerMainFeatureControlFEATURE_NATIVE_DOCUMENT_MODE]
"MyApplication.exe"=dword:C350
Due to a known bug in the IE8 Beta 1 build, the User-Agent String returned by the browser instance will state that it is “MSIE 8.0” (as shown in the screenshot above). Knowledge Base Article 183412 provides a workaround for this scenario.
IE Version Targeting and WebBrowser Rendering Modes
As with webpages displayed in an IE window, pages hosted in a WebBrowser control can also override rendering settings by using the X-UA-Compatible meta tag to specify a rendering mode. For more information on formatting and values for the version targeting META tag see Scott Dickens’ latest post here.
Matthew David Crowley
Program Manager
Internet Explorer Extensibility
Note: The feature control key and mode information in this post is now outdated. Please refer to the updated post on this topic: https://blogs.msdn.com/ie/archive/2009/03/10/more-ie8-extensibility-improvements.aspx
Comments
Anonymous
March 18, 2008
PingBack from http://msdnrss.thecoderblogs.com/2008/03/18/webbrowser-control-rendering-modes-in-ie8/Anonymous
March 18, 2008
Microsoft hat sich vor der Veröffentlichung einer Beta-Version des kommenden Internet Explorer 8 (IE8) nun doch (einigermaßen überraschend) dazu entschlossen, die ggü. IE6 und IE7 standardkompatiblere Darstellung von Webinhalten standardmäßig zu verwendeAnonymous
March 18, 2008
uhm.... The filename of an executable does not uniquely identify an application.Anonymous
March 18, 2008
>>IE8 renders pages running within instances of the WebBrowser control in IE7 Standards Mode by default.<< is incorrect. new:>>IE8 renders pages running within instances of the WebBrowser control in IE7 Strict Mode OR Quirks mode by default, depending on the page's doctype.<<Anonymous
March 18, 2008
"uhm.... The filename of an executable does not uniquely identify an application." I was just about to say that: What gives?Anonymous
March 18, 2008
Will we have a property on the contorl tocontrol renderig mode?Anonymous
March 18, 2008
Indeed, how could you miss such an obvious flaw with name non-uniqueness. Also, what happens when an application decides to change the rendering engine of another application (either maliciously or accidentally)? I don't really know how these apps invoke the rendering engine, but shouldn't you specify it then? Or maybe have separate DLLs or however it's handled for different versions?Anonymous
March 18, 2008
"The filename of an executable does not uniquely identify an application" No, it doesn't, but that's how IE feature controls have always worked. A key question is whether or not FEATURE_NATIVE_DOCUMENT_MODE is supported by CoInternetSetFeatureEnabled ( http://msdn2.microsoft.com/en-us/library/ms537168(VS.85).aspx) If so, then you don't need to muck about with the registry.Anonymous
March 18, 2008
Um, do you think you guys could use some sensible terminology around here? A web browser is an application that users use to browse the web. A reusable, embeddable chunk of code that renders HTML is not a web browser, it's an HTML engine/renderer/control/widget. Web browsers are applications. Web browsers use HTML engines. Other programs also use HTML engines. The phrase "per-application web browser control rendering settings" is rather confusing and requires multiple attempts to parse. This is due to per-application settings for a specific application (a web browser) being a pretty meaningless idea. IE8 is a web browser. The HTML rendering engine that IE8 uses, and which can be embedded inside other applications, is not a web browser. Would it be possible for you to use clearer terminology in future? Do you ever confuse yourselves and/or each other with such muddled use of terminology and language?Anonymous
March 18, 2008
I also see a problem with name uniqueness. Not in my own applications, but for all those autorun.ext, setup.exe, install.exe, etc. executables that use a web browser control. More important for me is however that I can also set a simple property on the control to change the rendering mode instead of setting registry keys. Since I'm using Windows Forms mainly, I guess I will have to wait some time until the .net wrapper will expose this property, but I'd still prefer that. Also how would a small application that usually runs directly from cd, etc. and does not have an extra installer switch to the standards mode. I wouldn't want it to write stuff in my registry just so that it can render websites correctly... Thanks.Anonymous
March 18, 2008
Hmm, I encourage this. But I'd wish you wouldn't use the filename but something that is unique. Or add a flag or something like that to the control...Anonymous
March 18, 2008
Our application embeds the WebBrowser control. Most of our HTML pages specify a DOCTYPE and load in IE7 Standards mode, while a few lack the DOCTYPE and thus load in quirks mode. VML in our pages only renders if the page is in quirks mode, not if it's in IE7 Standards mode. Is this a known issue that will be resolved in an future beta? BTW, thank you so much for making IE7 compatibility the default. I just set the registry key to force our application into IE8 mode, and immediately ran into a number of problems loading external script files. Not having to debug problems with our asynchronous pluggable protocol handler (the way we did when IE7 came out) is fantastic.Anonymous
March 18, 2008
@Bradley: For now, you must specify "inline-block" to get VML to render in strict/standards mode. Please see http://support.microsoft.com/default.aspx/kb/932175Anonymous
March 18, 2008
Karellen-- Where did you get the silly idea that the IE Web Browser Control (WebOC) is only able to host HTML? "Trident" is the HTML rendering engine used by the WebOC, but there are many other DocHosts available for other file types (PDF, Word, etc) Calling it a "rendering engine" is also incorrect because it performs navigation, travellog, and other functions. The WebOC is a web browser, no matter what skin you slap around it.Anonymous
March 18, 2008
Composite applications will also run into problems with this type of setting. For example, MMC snap-ins, Office, and Visual Studio addins frequently host the WebBrowser control. When the developer does not control the executable entry point, this method will not work. Ideally, this flag could be passed programatically.Anonymous
March 18, 2008
What's the feature control value to enable IE 8 standard mode in hosted control? And when is the SDK planned to released with the updated header file?Anonymous
March 18, 2008
This CAN create a potential issue esp setup programs which use the WebBrowser control. What if 2 SETUP.EXEs are running at the same time?Anonymous
March 19, 2008
This doesn't seem like a good way to fix the problem. Needs more brainstorming. "webmasters can easily alter their site to render properly in the new version of IE" That's an understatement ;-) "many software vendors do not have the resources to instantly push out new versions of their applications with updated internal pages". How many common applications would suffer (seriously) from having IE8 rendering by default? (using the same DOCTYPE-based rendering as IE8 does) In what scenario would you want to embed static HTML in an EXE/DLL? Doesn't seem like good a design choice.Anonymous
March 19, 2008
IIRC windows supports side by side versioning of controls or other libraries. They used this feature to provide the new (themed) common controls to applications that wanted it in windows xp while older applications still got the old version. Wouldn't that be a good solution for the web browser control? I have no idea however how difficult that'd be to implement for you though....Anonymous
March 19, 2008
Any chance of application/xhtml+xml support in IE8? Or if not in 8, then perhaps in version 9?Anonymous
March 19, 2008
Even assuming you've given your application a meaningful name that no one else would use, this method also does not allow different versions of the same application to use different settings. It is not uncommon for users of our application to have multiple versions installed for compatibility with files the receive or send to other companies. Just because IE insists that there can only be one version of itself installed at a time doesn't mean that other programs work the same way.Anonymous
March 19, 2008
The comment has been removedAnonymous
March 19, 2008
When I see stuff like that, where:
- an embedded app requires modification of a system-wide setting,
- said setting doesn't use a secure signature, heck, doesn't use a signature at ALL (filename, what a joke! At least it's not limited to 8.3!),
- versioning is non-existant on a system which is said to promote backward compatibility (what about Trident 6 Strict mode?), I think it may be time for some developers to have a long, hard look at Mozilla's XUL.
Anonymous
March 19, 2008
They have, what, half a year until the public non-beta of IE8 is released, which should be more than enough time to get their stuff together. Make the IE8 rendering default; fuel progress!Anonymous
March 19, 2008
Franklin - Oh, thanks for that. I didn't realise that the web browser control rendering modes (which is what this article is about, and which I was directing my comment at) also affected PDF and Word documents. Tell me, how exactly does this IE7 standards mode affect these other doc hosts? Or were you trying to point out that the very confusion I was trying to bring people's attention to is caused (as I suggested) by the use of the phrase "web browser control rendering modes" instead of, say, "trident control rendering modes"?Anonymous
March 19, 2008
What about acid3? IE is still worst browser looking on that test....Anonymous
March 19, 2008
"What about acid3? IE is still worst browser looking on that test...." I'd rather have them focus on the essence, instead of trying to impress people by passing exotic test suites (which no browser passes at this moment)Anonymous
March 19, 2008
The comment has been removedAnonymous
March 19, 2008
"What's the feature control value to enable IE 8 standard mode in hosted control? And when is the SDK planned to released with the updated header file ?" "A key question is whether or not FEATURE_NATIVE_DOCUMENT_MODE is supported by CoInternetSetFeatureEnabled ?" Yep, thanks, those are the salient questions. Bound to be documented pre release.Anonymous
March 19, 2008
@EricLaw: To clarify, the pages render fine if either IE6 or IE7 is installed. (The pages have a DOCTYPE and so render in those browser versions' respective Standards Modes.) So it's not a problem with rendering VML in strict standards-compliant mode, which the KB article is addressing. When IE8 is installed, VML stops working, even though IE8 is supposed to be rendering the pages in IE7 Standards Mode, just as if IE7 were the installed browser version. This seemed like it might be a problem with IE8's implementation of IE7 Standards Mode, so I wanted to make sure it was brought to the IE team's attention.Anonymous
March 19, 2008
@Bradley: Thanks for getting back to me. Any chance you can email me one of the pages as a test case ( @microsoft.com )? Thanks!Anonymous
March 19, 2008
So, aside from the non-uniqueness of an applications exe name, there is also the fact that you are encouraging application writers to write to parts of the registry that don't belong to their application! That's a bad idea. It would make much more sense to include this sort of information in an applications manifest. That way it's guaranteed to be: a) Application specific b) Safe(r) c) PortableAnonymous
March 19, 2008
See, when I tried the IE8 Beta, my AIM/DeadAIM was crashing hourly. Does this have anything to do with this? It runs fine now that it's back to IE7.Anonymous
March 19, 2008
http://www.sezwho.com/blog/2008/03/19/casual-encounter-with-ie8/Anonymous
March 19, 2008
The secret is described here best at http://heather48dd.bravejournal.com/entry/20870Anonymous
March 20, 2008
The mentioned registry entry works, it can also be set in the equivalent HKLM key by the way, which is handy if a global setting is desired. I found, however, that very many pages render as white, empty content in the IE8 WBEngine while displaying correctly in the IE8 Webbrowser on the same machine. This effect can be seen here: http://www.ipinfo.info/netrenderer/ Shouldn't both engines behave (almost) identically?Anonymous
March 20, 2008
@Bradley Grainger -- Support for binary layout/rendering behaviors, of which VML is an example, is not yet implemented in IE8 standards mode.Anonymous
March 20, 2008
The comment has been removedAnonymous
March 20, 2008
@Mac, IEdude, Paul R As of Beta 1, setting this value via CoInternetSetFeatureEnabled is unsupported. Understanding that this is a desired enhancement, we will take this under consideration for future builds.Anonymous
March 20, 2008
@Jonathan Hoersch: As far as I know, our pages are not rendering in IE8 Standards Mode (because they're displayed through the WebBrowser ActiveX control, which defaults to IE7 Standards Mode; to be doubly sure, I set the registry value to 11170 to force IE7 Standards Mode). When one of our pages has a DOCTYPE (and thus is rendered in IE7 Standards Mode by IE8) no VML appears. When the page is missing a DOCTYPE (and thus is rendered in quirks mode by IE8) VML does appear. So we know that IE8 can display VML under some circumstances. I just wanted to make sure it was a known issue that VML is not showing up in IE7 Standards Mode. Thanks, BradleyAnonymous
March 20, 2008
Bradley -- if it works on quirks mode pages, but not IE7-mode pages, then it sounds like you need to make the top-level VML element an inline-block like Eric mentioned (http://support.microsoft.com/default.aspx/kb/932175). You should have seen this same behavior when IE7 was installed.Anonymous
March 20, 2008
Hi, Alltho IE8 is starting to look realy good, there is a few things that do concern me / things i hope you would consider to add to this version. (1) Faster javascript I tested IE8b1 against latest Firefox (Firefox 3, beta 4) and Safari, and was sad to see that my favorit browser ended in the bottom. (2) Better rendering Guys/girls, try and test www.startforce.com (realy cool WebDesktop), it renders so bad in IE8 (but very good in IE7) (3) XUL Support XUL is prety cool, i have seen many cool addons out there so faar, and would love in IE could get support for it. (4) Portable Since many of us devleopers rely on being able to use a large amount of browers to test things, it would be realy nice to have IE8 as a portable application on eg. www.portableapps.com (5) Download Manager I remember the days under Longhorn 4074, where there was included a download manager.. realy nice idea... I hope your team will take these in their consideration.Anonymous
March 21, 2008
The comment has been removedAnonymous
March 25, 2008
You can use the BrowserObject .NET control to determine the client render engine and display the HTML differently. Download the Free Edition now. <a href="http://www.browserobject.com">http://www.browserobject.com</a>Anonymous
March 27, 2008
The comment has been removedAnonymous
November 14, 2008
Mit Erscheinen des Internet Explorer 8 wird auch wieder das Problem auftreten, das einige Webseiten aufgrund von fehlerhaftem Quelltext oder Fehlern in der Engine des Browsers nicht korrekt angezeigt werden. Andere Webseiten dagegen werden erst mit derAnonymous
March 10, 2009
We’ve made a few improvements to our extensibility model in IE8 RC1 based on feedback we’ve received