My users are getting the following in IE 11 (Discourse version v1.9.0.beta2 +218) on Windows 10:
I don’t see this on meta or https://try.discourse.org/ in IE 11 on the same browser, so I thought that maybe a plugin is causing the problem. When I enter into safe mode and disable everything, I still get the error message.
Any additional troubleshooting suggestions to help determine what might be happening?
Safe mode does not cover everything – server side effects of plugins still exist.
So the only way to test for server side issues with plugins is to remove them one-by-one in the yml and rebuild?
This is what we’re running:
Are there any known IE 11 issues with any of those?
No, those are all official and should not cause problems. It is very weird that you cannot reproduce this on try!
There is something different about your instance, somehow.
Any suggestions about how to find that difference 
We’re running a docker based install on Ubuntu on a local virtual machine in case that makes any difference. We also are using SSO and require users to have an account to access the site (which is different from try and meta).
Can you get to a JS console on this browser and check the value of window.ie ?
Total JS developer noob here, so please bear with me. I dropped to the IE 11 console and typed alert(window.ie) and got an undefined back. Not sure if that is the proper way to go about getting that information though, so glad to try something else if I’m doing it totally wrong.
I did verify earlier via http://whatbrowser.org/ and that site believes that it is IE 11.
The script that shows this message is pretty straightforward, so I recommend following it and testing each variable to find why this message is appearing.
I think window.ie doesn’t exist. It was set at one point in an html conditional but was removed:
As Falco said, it’s a simple script, and window.ie doesn’t need to be defined, as long as window.history.pushState is truthy and the UA doesn’t include “Android 2.2” or “Android 2.3”, the warning bar won’t be shown.
Our developer is back in the office later this week, so I’ll see if he can help me step through some of this and we’ll update the thread.
I’ve just had a fiddle with an IE11 browser I’ve got laying around, and if you hit F12, click on the “Console” tab, you get what you need. If I type:
window.ie
it prints
undefined
If I then type
window.history
it prints
[object History] (other gibberish)
If I then type
window.history.pushState
it prints
function pushState() { [native code] }
If I type
navigator.userAgent.indexOf("Android")
it prints
-1
If you get results different to these, please post a full screenshot of the results you do get. If you get the same results, but IE11 is still causing you problems, then please provide a publicly-accessible URL (the site you linked to earlier is buried behind mandatory SSO) that exhibits the problem.
Here is what I’m getting:
window.ie
undefined
window.history
{
length: 1
}
window.history.pushState
undefined
navigator.userAgent.indexOf("Android")
-1
If I run the same process on meta, I get results similar to yours. It “feels” like a mandatory login + SSO problem. Do you know of any other similar sites you folks host that we could see if they’re having the same issue on IE 11?
Because of the type of data we have, we’re not able to make our site publicly accessible. But in the past I’ve PM’d folks on the team with temporary credentials if that would work.
If window.history.pushState is undefined, there’s your problem – if that’s false, you’ll get told your browser is too old. I’m not an expert on this part of things, but my understanding is that that is something that is provided by the browser (as part of the browser’s support for HTML5), not by Discourse, so it’s a bit mystifying that it would be undefined in an otherwise modern browser. Where things get super weird is:
That suggests to me that there’s something, somewhere in your site that is undefining that key. If you were running any freaky plugins, I’d definitely be giving them some epic side eye, but as you’re apparently sticking to the straight and narrow, I guess that isn’t likely. On the other hand, a binary search of the impacted plugins would only involve a max of five rebuilds, so it might be worthwhile giving it a try (I’d start with a no-plugins rebuild, just to validate that the problem is in one of them, and then go splitsies thereafter). If that doesn’t provide any diagnostically useful results, or a few rebuilds are just totally out of the question, I’m going to have to defer to someone else on the @team who has ninja skills in JavaScript debugging to give some guidance, whether that’s some further stuff you can try in the IE11 console, or perhaps just “temp creds please, I need to rummage around”.
Look at the warning at the top: The attached page targets document mode 7. Some console APIs and features may not be available.
Something is making IE run in compatibility mode. Search Stackoverflow, there are some questions that seem relevant.
This might be relevant to Discourse:
Good catch. I brushed straight over that. Most of the stuff I can find on that error talk about fixing it by setting X-UA-Compatible (via http-equiv meta tag, usually), but as far as I can see meta doesn’t do that, either, so it presumably isn’t a panacea, nor generally necessary for Discourse.
I’ve found some posts talking about compatibility modes being set in a list; is it possible the browsers you’re all using have been configured to have your site on an IE compatibility mode list? I’m thinking this might be doable via, say, site-wide group policies or something similar. I can rule that out, at least, if you PM me some temp creds – if I can load the page OK, it’s a browser config issue.
Meta isn’t on an intranet. Maybe this is the problem:
Really great detective work that is almost certainly it; on your local network ie11 is forcing old browser compatibility mode.
We should just add the header back