Should be done in Vector itself, probably, so moving to that component and assigning to Trevor.

1.17? We need this now or ASAP to be more exact.

(In reply to comment #2)

1.17? We need this now or ASAP to be more exact.

The way I understand it that field is for the affected version, not the version for which the fix is planned.

(In reply to comment #3)

(In reply to comment #2)

1.17? We need this now or ASAP to be more exact.

The way I understand it that field is for the affected version, not the version
for which the fix is planned.

At least on pl.wiki I see 1.16wmf4 (r73744).

Created attachment 7719
IE8 in Compatibility Mode on pl.wiki main page

Could somebody push this forward? We have quite a lot IE8 users in Poland and for most of them our main page looks bad (see attached picture).

Our browser stats:
http://www.ranking.pl/en/rankings/web-browsers.html

Please take care of this ASAP, thank you.

Attached:

We've managed to work this out differently so not in a hurry any more.

Closing as WORKSFORME, not needed since two years, and it looks like nobody cares anymore.

Also, I'm not sure how it relates to the original bug, but this just might have been fixed when WMF wikis switched to HTML5 doctype.

IE's compatibility mode is still available and can be switched in by accident in IE 8/9/10 -- the doctype only helps with our default mode, apparently.

This can break rendering and cause issues such as bug 54343.

We should include an 'X-UA-Compatible: IE=EDGE' header or meta tag in output (not specific to any skin please!) to ensure this can't be used...

Some users of the Semantic Forms extension just experienced this problem - they couldn't use SF on their internal wiki with IE10, because IE10 has the "compatibility view" turned on by default for intranet sites, and with the compatibility view the (jQuery-based) JavaScript of SF stopped working.

Anyway, modifying the file /includes/OutputPage.php in the following way fixed it:

Below these lines, around line 2520:

$openHead = Html::openElement( 'head' );
if ( $openHead ) {
        # Don't bother with the newline if $head == ''
        $ret .= "$openHead\n";
}

...add the following line:

$ret .= Html::element( 'meta', array( 'http-equiv' => 'X-UA-Compatible', 'content' => 'IE=10; IE=9; IE=8; IE=7; IE=EDGE' ) );

I don't know if the stuff besides "IE=EDGE" is necessary - that's what I found online. I do know that it's important to have this be the first <meta> tag; otherwise it apparently won't work - see here: http://twigstechtips.blogspot.com/2010/03/css-ie8-meta-tag-to-disable.html.

'IE=10; IE=9; IE=8; IE=7;' are all unnecessary. 'IE=EDGE' is sufficient and is precisely what we want: At any time, the most standards-compliant mode available.

Also, the X-UA-Compatible tag doesn't need to be the first <meta> tag. Other <meta> tags and the <title> tag are allowed to come before X-UA-Compatible:

"[...] it must appear in the header of the webpage (the HEAD section) before all other elements except for the title element and other meta elements."

Source: http://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).ASPX

Please put this tag *after* <meta charset> because the HTML specification requires <meta charset> to come very early and X-UA-Compatible isn't conforming in HTML5 anyway.

I just created a patch for this, here:

https://gerrit.wikimedia.org/r/103387

(Sorry, I don't know how to automatically associated Gerrit patches and Bugzilla bug reports.)

(In reply to comment #11)

(Sorry, I don't know how to automatically associated Gerrit patches and
Bugzilla bug reports.)

See http://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines :)

Change 103387 had a related patch set uploaded by Yaron Koren:
Fix to avoid IE "compatibility view"

https://gerrit.wikimedia.org/r/103387

Patch associated. :)

Change 103387 merged by jenkins-bot:
Fix to avoid IE "compatibility view"

https://gerrit.wikimedia.org/r/103387

I'm going to tentatively mark this as resolved per the patch above. If the issue persists with the patch (which will be deployed on Wikipedias on Thursday, 30 January 2014), please reopen this bug and we'll investigate.

This causes a new bug. See bug 62885

Change 421440 had a related patch set uploaded (by Krinkle; owner: Ejegg):
[mediawiki/core@master] OutputPage: Remove 'X-UA-Compatible' header (was for IE8-10 JS compat)

https://gerrit.wikimedia.org/r/421440

Change 421440 merged by jenkins-bot:
[mediawiki/core@master] OutputPage: Remove 'X-UA-Compatible' header (was for IE8-10 JS compat)

https://gerrit.wikimedia.org/r/421440