Internet Explorer 8

pieterdv · Post by **pieterdv** » 30 Apr 2012, 14:15

I have several staff members that get the same message that IE ver 8 is too old a browser.

I understand from release notes that IE 8 should be OK though.

Any idea by anyone of what would cause the problem?

EXG133 · Post by **EXG133** » 07 Aug 2012, 10:37

Check the Compatibility View. I had the same thing, apparently our IE8 has 'use Compatibility View for all intranet websites' enabled by default. For you it might be that setting or the user clicked on the View button.

greenskol · Post by **greenskol** » 04 Sep 2012, 10:53

Hi,

We're currently having the same issue, and I'm sorry to say that OTRS is bugged regarding this specific IE feature (and their support simply refuse to take our complaint into consideration...).

With IE8 Microsoft introduced a way for web developers to force Internet Explorer rendering mode using a specific META tag ("X-UA-Compatible").
If this tag is not used, in order not to break rendering of existing corporate applications, all intranet websites are using by default the "IE7 compatibility mode".

Here's Microsoft official documentation on this topic:

Defining Document Compatibility
http://msdn.microsoft.com/en-us/library ... s.85).aspx

How to Detect Features Instead of Browsers
http://msdn.microsoft.com/en-us/library ... s.85).aspx

I started digging into the error and here's what I've found:
The initial code that triggers the browser check on the login page is the following:

Code: Select all

// begin Core.Agent.Login.js
 
"use strict";
var Core=Core||{};
Core.Agent=Core.Agent||{};
Core.Agent.Login=(function(TargetNS)
{
     TargetNS.Init=function(LoginFailed)
     {
           if(!Core.Debug.BrowserCheck())
           {
                $('#LoginBox').hide();
                $('#OldBrowser').show();
                return;
           }
(…)

After following the code, we end up here :

Code: Select all

// begin Core.Config.js
TargetNS.AddConfig({
 
(...)
        'Microsoft Internet Explorer 7': function () {
            var detected = ($.browser.msie && $.browser.version === '7.0');

            // IE8 in Compatibility Mode will claim to be IE7.
            // See also http://msdn.microsoft.com/en-us/library/ms537503%28v=VS.85%29.aspx
            if (detected && navigator && navigator.userAgent && navigator.userAgent.match(/Trident\/4.0/)) {
                alert('Please turn off Compatibility Mode in Internet Explorer.');
            }

            // IE9 in Compatibility Mode will claim to be IE7.
            if (detected && navigator && navigator.userAgent && navigator.userAgent.match(/Trident\/5.0/)) {
                alert('Please turn off Compatibility Mode in Internet Explorer.');
            }

            return detected;
        },

(...)

Based on this it's clear that the script is only checking the user agent, completely ignoring the new Document Compatibility setting in IE8 & IE9...
As all OTRS web pages seem to correctly include the proper "X-UA-Compatible" tag to force latest IE rendering engine, this is kind of "stupid", isn't it ?

Code: Select all

<head>
(...)
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"/>
(...)
</head>

In order to test the "real" compatibility mode used, Microsoft recommends to use the "document.documentMode" property.

Anyway, to test that OTRS is properly working, I've done the following:
- manual switch to "IE 8 Standards" mode at login page (using F12 developer tools) to bypass the faulty script,
- once at the dashboard, switched back to "IE 8 Compatibility view".

Until now everything seems to work perfectly fine, and I'm really curious to know what are the "limitations that are coming with IE8 in compatibility modus regarding rendering and css." OTRS support is telling us about without providing any proper technical details.

Answering a corporate client to "just disable compatibility view on IE8 or IE9" is a little bit "naive", especially as we currently have more than 300 agents across our organisation. Fixing a bugged script seemed smarter that deploying specific IE settings on 300-400 computers...

Regards,

Stéphane

jojo · Post by **jojo** » 04 Sep 2012, 11:51

This behaviour is already stated in the release notes. So it is not a bug!

Post by **crythias** » 04 Sep 2012, 13:40

For a large organization, they should be familiar with and use GPOs internally to address this issue.

http://technet.microsoft.com/en-us/libr ... 85351.aspx
Windows Components\Internet Explorer\Compatibility View
Turn on Internet Explorer 7 Standards Mode
Turn off Compatibility View
Turn on Internet Explorer Standards Mode for Local Intranet (enable this: it makes intranet behave >IE7)
Use Policy List of Internet Explorer 7 Sites (enter list of "must be IE7 sites)
Turn off Compatibility View button
Include updated Web site lists from Microsoft

Kernel/Output/HTML/Standard/HTMLHead.dtl says:

Code: Select all

#    IE(8,9) renders pages differently, depending on the source of the page. If the page comes from the intranet,
#    it renders it in IE7 mode, if the page is loaded from the internet, it will be rendered in IE8 mode by default.
#    To avoid that, we set "IE=edge", which means, that IE renders the page always in the best render mode it can.
#    "chrome=1" means, that the Google Chrome rendering engine is used in IE, if the Google Chrome Frame plug-in
#    is present.
    <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />

If you don't want to use "edge", change it to "IE8"

Znuny Open Source Ticketsystem

Internet Explorer 8

Internet Explorer 8

Re: Internet Explorer 8

Re: Internet Explorer 8

Re: Internet Explorer 8

Re: Internet Explorer 8