For completeness, see http://stackoverflow.com/questions/26346917/why-use-x-ua-compatible-ie-edge-anymore

Yup, though I want to point out in this case the default IE 11 install on win7 forces compat mode on intranets. so it's more a case that your administrator needs to force it off, or you need to do it yourself to get phab working.

Yeah, we're also affected by this... it's mostly a non-issue since no one really uses IE but IE11 renders incorrectly in IE7 compatibility mode since the Phabricator server is determined to be in the intranet domain.

It seems reasonable that Phabricator could set the X-UA-Compatible HTTP header (not meta tag) in responses?

Or, document as part of the https://secure.phabricator.com/book/phabricator/article/configuring_preamble/ setting:

<?php
header('X-UA-Compatible: IE=edge');

For users who have environments that care about this? (I just tested this... and it appears to work, at least causes the log-in page to render less-ugly)

The meta header causes all IE versions to re-render the page twice, incurring a performance penalty.

I don't know if @epriestley thinks we should force the header at the PHP level or not. We get roughly 1 report of this per year. Win7 was EOL'd in Jan 2015, so I'm surprised people are still installing it fresh.

Did you guys know that Microsoft is offering a FREE upgrade to Windows 10!
[ Schedule Upgrade NOW ] [ YES! ] [ W-o-w ] [ Reserve Your Windows 10 Today ]

I think the incidence of this is so low (and should continue to fall in the future) that it's not worth bringing upstream.

I wouldn't want to bring it upstream without testing it properly, which is very hard to prioritize given how little we see of it, nor do I want to document something we haven't tested.

My crude calculus here is that it's currently far less costly for us to just tell users who report this issue to turn of compatibility mode twice a year than it would be to properly test this change across multiple Windows versions/browsers/settings, and the cost should only decrease in the future, and it also saves us from having to do all that testing again some day when we want to remove the header.

I vaguely remember these headers really not being very simple last time this came up, too, although maybe I'm misremembering and can't immediately find the discussion.

If someone under the "Rise to prominence" clause of Contributing Code sent us a diff and promised they'd totally tested it really well I'd be comfortable upstreaming it, but I don't want to put that much trust in a drive-by contributor since I'm the one who is going to have to spend a bunch of time mucking around with IE if the change actually breaks things.

T6547 was the other task, which points to a conversation on GH which no longer exists.

I'm 100% fine with that, I have no idea if there's some ugly interactions here, just wanted to chime in that we were affected too. The average skill level of users interacting with Phabricator makes the workarounds not a big deal in general (although I think an administrator can lock users out of the necessary IE settings to turn off compatibility mode)

I'll leave that setting turned on in my preamble.php but I don't think we have users that will really be able to exercise it thoroughly enough for me to promise it is well tested. All our users either use chrome, or tried IE and switched to chrome without bugging me.

@epriestley way too much optimism about how fast enterprises move to new versions of windows/IE :), there's a lot of people that still have to keep old IE versions running to access internal applications (not just speaking from our own environment, sadly)