Nah, I object to serving this header 100% of the time to everyone to fix the .01% of the time this is an issue.
I’m disturbed by the idea that IE11 would assume, prima facie, that anything “local” (same subnet? on any RFC1918 address?) would require compatibility mode.
It is possible that we have it in our Trusted zone to allow users to access the site without having to log into it directly (uses Windows credentials). I’ll have to check when I get back to the office later this week.
2 Likes
Talk to your windows administrator. They may have implemented a group policy which forces IE to do this.
2 Likes
Let’s be fair: MS knows perfectly well that one of IE’s greatest use cases these days is legacy intranet applications that are designed to run with old IE versions. So designing IE 11 to cater specifically for this precise extremely common situation (which they did, see first setting) is not really all that crazy. The fact they put it behind Group Policy is even more reasonable.
Having run a large MS based corporate network, I can attest to the fact that one of the biggest headaches is dealing with some legacy app which is “business critical”, but “too expensive to rewrite”. Group policies are one way of limping along by ignoring the underlying issue, but there is a tendency to cast the net too wide.
Not sure if this is helpful / or you already know, but to disable compatibility mode, go to tools > compatibility mode settings and uncheck the display intranet site in compatibility view setting / or remove the discourse site from the compatibility sites list.
6 Likes
Unfortunately, changing Compatibility View Settings in our corporate environment is not possible due to restrictions and some other issues.
I have tried going the route of adding the header from within the container:
added add_header “X-UA-Compatible” “IE=Edge”; in /etc/nginx/conf.d/discourse.conf below “server {”
and restarted nginx (service nginx stop; service nginx start;)
as well as added “<meta http-equiv=“X-UA-Compatible” content=“IE=Edge,chrome=1” />” via Customize -> Edit CSS/HTML.
The first workaround added the header in a v1.8.x Discourse deployment, but same thing done in a v1.9.x deployment does not work. I checked the headers with Fiddler and the additional header is not in there with v1.9. The additional meta-tag is indeed in, but does not “switch off” compatibility mode, maybe because it is too far below and not the first meta entry.
Tried a complete rebuild and then changing the dicourse.conf again, too - just to exclude that I messed up something - same effect.
I am trying to get v1.9.x working with IE11 in the local network since a while now and am a bit lost I have to admit. I have opened a topic some while ago, too, and have been asked to continue here: https://meta.discourse.org/t/ie11-in-compatibility-mode-intranet-is-getting-your-browser-is-too-old/66185
Is there anything I’ve missed in terms of changes made to the nginx-setup within the container in v1.9? Do I need to set the header elsewhere, too?
Thanks a lot in advance and cheers
Thomas
2 Likes
QUOTE: Unfortunately, changing Compatibility View Settings in our corporate environment is not possible due to restrictions and some other issues.
Can anyone help to overcome this issue; since as quoted below; if we are to try deploying discourse in Corporate Intranets; many will face similar issues.
Thanks!
Discourse does not support being run in IE11 “compatibility mode”, if that is a requirement, then you will need to choose different software.
1 Like
We have worked around the issue by establishing an additional nginx-instance proxying discourse and adding the appropriate headers to disable compatibility mode.
3 Likes
Adding the header is pretty easy in a hook nginx already runs in the discourse container
3 Likes
This topic was automatically closed after 2531 days. New replies are no longer allowed.