Page MenuHomePhabricator

[SOLVED] css does not display on ie11 on intranet
Closed, InvalidPublic


I had a user have problems with phabricator loading on Internet Explorer IE 11 on a windows 7 box he built himself, the site seemed to be having problems displaying the css since a lot of the styles were missing. The site was really not functioning and you couldn't click on the controls.

Most of us use chrome/firefox or the IE11 provided by corporate IT, and have no problems.

I was able to replicate the problem on a new windows 7 install with default IE 11 I built myself. After some googling and debugging of the dev console, I was able to find the users problem, by default IE 11 under Compatibility View settings the option Display intranet sites in Compatibility View is checked by default.

Unlike many of our intranet sites, phabricator definitely does not like being rendered like this. It's completely unusable. We run phabricator locally on our intranet.

tl;dr: If your phabricator is on an intranet, you need to disable compatibility view for all intranet sites in ie11 options. Or at least for your phab install add the url to ie11.

I doubt phabricator can detect that it is being rendered this way and display some kind of warning / instructions to users.

I'm not sure if you want to make a note of this in the docs, either user guide or install guide warning admins of this problem. Hell maybe it's already there and I missed it, though google didn't bring it up when I was searching for this problem.

In any case I searched for a ticket and didn't find any so please feel free to close this ticket as WONTFIX, at least the solution will be searchable in the future for others.

Related Objects

Event Timeline

ofbeaton renamed this task from css does not display on ie11 on intranet to [SOLVED] css does not display on ie11 on intranet.Apr 15 2016, 5:32 AM
ofbeaton created this task.
chad added a subscriber: chad.

IE7 and IE8 were end of lifed in January. I think most sites wouldn't work anymore with Compatibility Mode on. If a administrator forces it on, it's on. Not much we can do.

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 setting:

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)