5

I'm working on a web product that may be hosted as an intranet site. I'm trying to find a programmatic way to keep IE9 from slipping into IE9 Compatibility View browser mode, even though 'Display Intranet sites in Compatibility View' may be on.

I'm testing with this html page:

<!DOCTYPE HTML>

<html>
    <head>
        <meta http-equiv="X-UA-Compatible" content="IE=9" />
        <title>Company</title>
    </head>
    <body>
    </body>
</html>

I've put this in IIS config:

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <clear />
            <add name="X-UA-Compatible" value="IE=edge" />
        </customHeaders>
    </httpProtocol>

as recommended here: https://stackoverflow.com/a/5887546, and checked the response headers in IE9 and see:

X-UA-Compatible     IE=Edge

But the page still puts the browser in Compatibility View browser mode.

The console shows:

HTML1202: http://intranet-site/test.html is running in Compatibility View because 'Display intranet sites in Compatibility View' is checked. 
test.html

There's a similar question here: https://stackoverflow.com/a/3726605/1279516, in which a comment by Jacob on the chosen answer suggests that in IE9, there's nothing you can do to override the 'Display Intranet sites in Compatibility View' setting. However, his comment is the only place I've found mention of this. Can anyone confirm or deny that assertion?

And is there anything else I can try? I shouldn't have to tell all clients who deploy our product to uncheck the 'Display intranet sites in Compatibility View' browser setting for all their users.

Community
  • 1
  • 1
jcairney
  • 1,817
  • 1
  • 14
  • 16
  • Which document mode do you see in the IE development tools for your site? – oryol Mar 20 '12 at 14:06
  • The document mode is actually IE9 standards. That ensures the rendering is done in standards mode, but not that all the javascript features are available, correct? – jcairney Mar 20 '12 at 15:17
  • 2
    No, actually you should check only document mode. Browser model is initial parameter which determines how document mode should be calculated (by default). So, if you have correct document mode then everything should work as expected. – oryol Mar 21 '12 at 11:40
  • The feature I thought I was missing was .querySelector() - only available when document mode is IE8 standards or higher. A brief test added to the above html confirmed that .querySelector is available even when browser mode is IE9 Compatibility View (IE8 Compatibility View in IE8). – jcairney Mar 21 '12 at 15:13

2 Answers2

2

Unless someone says otherwise, oryol's comment suggests that all features are made available based on Document Mode, so there's no need to try to control browser mode further once you are getting the document mode you want.

jcairney
  • 1,817
  • 1
  • 14
  • 16
0

I ran into a similar issue - page not rendering correctly in IE8/9 because Display Intranet sites in Compatibility View was on. Asking all users to disable this or asking for a group policy and adding exceptions for I do not know how many other intranet pages requiring this was not an option. The document mode is OK thanks to the X-UA-Compatible: IE=edge. But I still had the layout issues.

Cause: Compatibility mode causes IE to send another user agent to the server. For IE8,9 this is that of IE7. Some of my ASP.NET libraries does some checks based on that and renders IE7 specific HTML/CSS that results in layout issues.

Solution: Modify the UserAgent string on the server to "IE9" if it says "IE7". Of course this is a dirty solution since in theory there could be a real IE7 client. In my cause (Intranet) I know my users only have IE >= 8. Changing the UserAgent proved harder than anticipated. I successfully applied this idea - deriving a subclass from HttpWorkerRequest and intercepting requests for UserAgent. This indirectly overloads request.UserAgent and helped solve the problem.

Community
  • 1
  • 1
Piper
  • 531
  • 7
  • 9