I am working on an intranet website within a corporate company where there is the Internet Explorer 8 (running on Windows XP, so cannot upgrade to IE9) used as a standard (and the only one) browser and I am dealing with the Compatibility View Mode feature. The website is based on ASP.NET 2.0 and the web server is Windows Server 2003 with IIS6.
It is not possible to switch to any other browser because some other critical third party web based applications require Internet Explorer (and ActiveX) to run properly.
I would like to ask whether there is a way how to (programmaticaly, using a http header ...) override the Internet Explorer's browser mode in case the Compatibility View Mode is turned on for Intranet websites by default or, in other words, how to force the Internet Explorer to use the IE8 Browser Mode rather than the IE8 Compatibility Mode.
I have tried to add the X-UA-Compatible http header set to IE=Edge (or IE=8) in the IIS configuration but it only affects the Document Mode, never the Browser Mode.
Thanks for any help.
Browser mode refers to the user-agent string and, IIRC, it controls the UA string that's sent to a server during HTTP negotiation. The only documented way to control that is to use the F12 developer tools.
You may want to look at Enterprise Mode[1] (EMIE), supported for Win 7 and later. When EMIE is enabled for IE, IE11 behaves and acts like IE8. This includes the UA String.
You are correct, x-ua-compatible controls only the document mode. There was a feature control key (FEATURE_BROWSER_EMULATION [2]) that might've helped, but it's unclear whether that's still supported in current versions of IE. (See the Extensibility Improvements link on that page for technical details.)
Hope this helps...
References:
[1] - http://technet.microsoft.com/en-us/library/dn640687
[2] - http://msdn.microsoft.com/en-us/library/ie/ee330730(v=vs.85).aspx#browser_emulation
Related
Our web browser plugin has worked in all IE versions and still works fine in IE9 and IE10 but in IE11 the plugin is not even recognized and listed as an add-on. It's as if IE11 no longer supports ActiveX.
NOTE: this questions is asked as the developer of the plugin and not the end-user who might need to correct IE settings. So suggestions for how to detect ActiveX or how to adjust a browser settings to allow ActiveX are useless here.
We assume that what we need to do is make adjustments to the ActiveX structure so that IE11 on Windows 8 approves the plugin so that it can be available to the user at their discretion, ie: list it in the Add-on Manager.
A sample project and test page can be downloaded from here - http://addmine.com/temp/EPM_project.zip
Surely there is a workaround but what do we need to change?
As of IE11, add-ons are supported only for IE on the desktop. If you're running the Windows Store experience of IE, then your statement about IE11 not recognizing the plug-in is absolutely correct. This article shows how you can have this experience prompt the user to open the page in the desktop experience of IE, which will support your plugin.
Having said that, it's entirely possible that you do change your plugin to support changes to the Windows 8 security model. Here are a couple of links to get you started:
Supporting enhanced protected mode (Note that this is part 1 of a four-part series)
IEInternals: Understanding Enhanced Protected Mode
IE Blog: Enhanced protected mode
Hope this helps...
-- Lance
I am trying to enable SPDY on web browser control (Internet Explorer 11/WIN 8.1).
In Internet Explorer advanced settings and in the registry the EnableSPDY3_0 is set to 1.
But in my web browser control the SPDY is not working.
Are there other settings that I need to configure?
How specifically are you attempting to detect SPDY?
I took a quick look with Fiddler and confirmed that SPDY is not used by the Web Browser control outside of IE itself. As this is a new and somewhat experimental feature, I'm not that surprised that the WebOC isn't using it yet.
If you rename your executable to iexplore.exe then you will find that SPDY is used. (WARNING: This isn't recommended for many functionality and security reasons.) That behavior indicates that they're using a FEATURE_CONTROL KEY to control whether SPDY is permitted; feature control keys work on a per-process basis.
I don't see a documented entry for this feature in the official FEATURE_CONTROL list. Internet Explorer's documentation writer and networking PM have confirmed that this is deliberately not documented and suggest that a bug be filed at connect.microsoft.com if you'd like to see a change in policy on this.
I have a VB6 application using the WebBrowser control. It displays HTML pages from a local folder (using file:// URI scheme). Some of those pages contain embedded JavaScript code.
It all works well for the vast majority of users, but occasionally we get reports from people who have problems with everything JavaScript-related in the pages. Basically, it looks like they have scripting disabled inside the WebBrowser control.
The problem is: I cannot even reproduce the problem. I was trying to fiddle with various settings in IE security (IE8 on Win XP Pro SP3), disabling various scripting-related options for different zones (which zone includes local file system, by the way?), - I'm always having JavaScript running well in my tests.
Does anybody have any idea of what may be going wrong?
Thanks
I think I know why this is happening, it's because the IE version the WebBrowser control renders under is IE 7.0 in most, and if they are using a browser older than IE 7, it will render under IE 4.0 (seriously). They do this for backwards compatibility. So if some of your users have IE 6, their default IE rendering engine will be IE 4.0. Of course, since you are probably using IE 9, yors would be IE 7 engine.
You can change the engine, if this is what you want to do, to the current engine (ie: to the current version of internet explorer installed on the users system).
Also, I'd like you to go to http://whatsmyuseragent.com/ on your IE browser, and then through the hosted WebBrowser control; you'll see the difference.
Also, ask your problemed users to go to http://whatsmyuseragent.com/ through their hosted WebBrowser control if they can, and note the results, if they are running pre-IE-7 then most likely their hosted webbrowser control will show IE 4.0. This is almost certainly the reason for your problem.
How is that possible?
http://img191.imageshack.us/img191/7080/wtfsg.jpg
Any solution to separate IE8 from IE7?
To quote this article on IEBlog:
IE8 will send the “MSIE 7.0” version information when viewing sites with Compatibility View enabled. (...) A new “Trident” token in the User-Agent string allows your code to detect Internet Explorer 8 clients even when they are using the Compatibility View feature.
To wit, your page is displayed in Compatibility mode, hence the UA change.
In this case you need to check from your developer toolbar if you are rendering your site as IE7.
You can get to the developers toobar by hiting F12 and checking the browser mode and puting it to IE 8.
I am thinking about using the TWebBrowser component that comes within Delphi's default pallet of components in a project, but I wonder if it uses the IE version installed on the client machine?
If yes:
then I guess it would share its history, cookies, workoffline and stuff like that?
Can I separate them somehow?
Is there any webbrowser component that is free and is not shared with Internet Explorer on the client?
The current answer is not quite correct. It appears for compatibility purposes, the WebBrowser control will run in IE7 Standards Mode by default unless you add some registry settings.
See:
WebBrowser Control Rendering Modes in IE8 (archive)
More IE8 Extensibility Improvements (archive)
So it's not quite the current IE version. You can also check this if you use fiddler or check the web server logs for the agent string - as it alters the agent string used too!
Yes, TWebBrowser uses whatever IE version is installed on the machine.
Take a look at this similar thread for some possible alternatives..
How to embed a browser object, other than IE<n>, in a Delphi application
Yes, TWebBrowser is tied to Internet Explorer. If you want a standalone HTML viewer, then look at the PBear components.
TWebBrowser is a wrapper around IE ActiveX interface.
So, in the end,
TWebBrowser = Internet Explorer