Last modified: 2014-03-21 18:54:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T27378, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25378 - Disable IE compatibility mode
Disable IE compatibility mode
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.16.x
All All
: Normal enhancement (vote)
: 1.23.0 release
Assigned To: Yaron Koren
:
Depends on:
Blocks: 49548 24194 47506 54343
  Show dependency treegraph
 
Reported: 2010-09-30 17:50 UTC by Nux
Modified: 2014-03-21 18:54 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
IE8 in Compatibility Mode on pl.wiki main page (152.44 KB, image/jpeg)
2010-10-05 21:19 UTC, Nux
Details

Description Nux 2010-09-30 17:50:28 UTC
Our current main page looks bad in compatibility mode and I'd like to request adding a met tag to fix this.

Code to be added:
<meta http-equiv="X-UA-Compatible" content="IE=edge" />

This will enable latest version of IE.

BTW. I think it might be a good idea to add this for all wikis in Vector.
Comment 1 Roan Kattouw 2010-10-02 19:06:44 UTC
Should be done in Vector itself, probably, so moving to that component and assigning to Trevor.
Comment 2 Nux 2010-10-03 08:52:13 UTC
1.17? We need this now or ASAP to be more exact.
Comment 3 Roan Kattouw 2010-10-03 13:15:38 UTC
(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.
Comment 4 Nux 2010-10-04 02:16:13 UTC
(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).
Comment 5 Nux 2010-10-05 21:19:30 UTC
Created attachment 7719 [details]
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.
Comment 6 Nux 2010-10-09 23:15:38 UTC
We've managed to work this out differently so not in a hurry any more.
Comment 7 Bartosz Dziewoński 2012-11-17 17:41:34 UTC
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.
Comment 8 Brion Vibber 2013-09-23 20:37:42 UTC
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...
Comment 9 Yaron Koren 2013-11-08 17:14:56 UTC
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.
Comment 10 entlinkt 2013-11-09 12:12:21 UTC
'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.
Comment 11 Yaron Koren 2013-12-23 18:15:52 UTC
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.)
Comment 12 Andre Klapper 2013-12-23 18:50:48 UTC
(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  :)
Comment 13 Gerrit Notification Bot 2013-12-23 19:51:10 UTC
Change 103387 had a related patch set uploaded by Yaron Koren:
Fix to avoid IE "compatibility view"

https://gerrit.wikimedia.org/r/103387
Comment 14 Yaron Koren 2013-12-23 19:53:24 UTC
Patch associated. :)
Comment 15 Gerrit Notification Bot 2014-01-14 21:21:50 UTC
Change 103387 merged by jenkins-bot:
Fix to avoid IE "compatibility view"

https://gerrit.wikimedia.org/r/103387
Comment 16 Bartosz Dziewoński 2014-01-14 21:36:49 UTC
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.
Comment 17 Jon 2014-03-21 18:54:59 UTC
This causes a new bug. See bug 62885

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links