JIRA
  1. JIRA
  2. JRA-25718

IE7 standards mode in IE8 and IE9 not to enable in JIRA

    Details

      Description

      Customers jira site is treated as local intranet site in our office environment, this cause IE9 and IE8 all use "IE7 standards" mode ( another colleague reported another bug when viewing a dropdown selection list on IE8, which is also caused by IE8 using IE7 standards more).

      See:
      http://sharovatov.wordpress.com/2009/05/18/ie8-rendering-modes-theory-and-practice/

      "If there's no X-UA-Compatible value and site is in Local Intranet security zone, it will be rendered in EmulateIE7 mode by default."

      The current workaround ( press F12, change it to IE9 standard for IE9 browser or IE8 standards for IE8 browser) only work for current IE instance, if I close all IE window and restart it again, I have to reset the browser mode for jira site again.

      I think a new feature can be added to jira like:

      if it found the client browser is IE8, send back header X-UA-Compatible to IE8;
      if it found the client browser is IE9, send back header X-UA-Compatible to IE9.

      IE7 mode in JIRA 4.4 has unpredictable behaviour as seen in the screenshot.

        Issue Links

          Activity

          Hide
          Adam Barylak added a comment -

          I have also noticed that the inline edit links for comments randomly disappear when it is set to IE7 standards.

          In addition to that, i have noticed that when accessing the JIRA instance from the local server running 4.4.1 it enables the correct standards, but not when accessing it from an external machine running IE8 or IE9. Yet, this version of JIRA at jira.atlassian.com works as expected with the correct IE standards. What is different between this instance and our installed instances?

          Show
          Adam Barylak added a comment - I have also noticed that the inline edit links for comments randomly disappear when it is set to IE7 standards. In addition to that, i have noticed that when accessing the JIRA instance from the local server running 4.4.1 it enables the correct standards, but not when accessing it from an external machine running IE8 or IE9. Yet, this version of JIRA at jira.atlassian.com works as expected with the correct IE standards. What is different between this instance and our installed instances?
          Hide
          Jamie Echlin added a comment -

          Voting up because this breaks one of my plugins.

          Show
          Jamie Echlin added a comment - Voting up because this breaks one of my plugins.
          Hide
          Falk Tischer added a comment -

          There are a lot of articles about IE browser and document modes.
          I think this one could be helpful for resolving the issue: http://blogs.msdn.com/b/ie/archive/2010/06/16/ie-s-compatibility-features-for-site-developers.aspx
          Also see the diagram "Determining Document Mode diagram for IE9" at the end of the article.

          Show
          Falk Tischer added a comment - There are a lot of articles about IE browser and document modes. I think this one could be helpful for resolving the issue: http://blogs.msdn.com/b/ie/archive/2010/06/16/ie-s-compatibility-features-for-site-developers.aspx Also see the diagram "Determining Document Mode diagram for IE9" at the end of the article.
          Hide
          Stefan Schweizer added a comment -

          Voting because we have to have CompVew Mode on for Intranet Zone. So having Jira working well in that mode would be extremely beneficial to us.
          Thanks!

          Show
          Stefan Schweizer added a comment - Voting because we have to have CompVew Mode on for Intranet Zone. So having Jira working well in that mode would be extremely beneficial to us. Thanks!
          Hide
          Adam Barylak added a comment -

          Robert-

          I noticed that you changed this issue from a bug to an improvement. What does that mean for this issue? Is this ever going to be fixed? It causes a lot of issues with other plugins as well as just usability of the product when you are in an Intranet environment which most companies are.

          I was also directed towards the includes\decorators folder for the header.jsp files, and i attempted to put in some javascript to set the correct meta tag as well as just hard-coding in the meta tag information, however the setting does not always work in your product even though it has been explicitly set correctly via the meta tag to the correct document mode.

          Let me know what can be done about this. Thanks.

          Adam

          Show
          Adam Barylak added a comment - Robert- I noticed that you changed this issue from a bug to an improvement. What does that mean for this issue? Is this ever going to be fixed? It causes a lot of issues with other plugins as well as just usability of the product when you are in an Intranet environment which most companies are. I was also directed towards the includes\decorators folder for the header.jsp files, and i attempted to put in some javascript to set the correct meta tag as well as just hard-coding in the meta tag information, however the setting does not always work in your product even though it has been explicitly set correctly via the meta tag to the correct document mode. Let me know what can be done about this. Thanks. Adam
          Hide
          Joey McDaniel added a comment -

          Within Login.jsp, I've set both the doctype and meta content type to force IE to use the latest standards mode. However neither of these customizations show and instead are being overwritten somehow with the JIRA default doctype / meta content type, which forces IE into IE7 document mode. Would love to see this fixed.

          Show
          Joey McDaniel added a comment - Within Login.jsp, I've set both the doctype and meta content type to force IE to use the latest standards mode. However neither of these customizations show and instead are being overwritten somehow with the JIRA default doctype / meta content type, which forces IE into IE7 document mode. Would love to see this fixed.
          Hide
          Adam Barylak added a comment -

          We were able to find a partial solution to this issue. By adding the following code to both header.jsp and header-deprecated.jsp files in the includes\decorators folder we are able to enable the correct Document Mode.

          <meta http-equiv="X-UA-Compatible" content="IE=edge" />

          However, that code needs to be the first thing after the <head> tag in both those files in order to take effect. Apparently the 'edge' value is not recommended for production use, but it seems to fix a lot of the issues.

          However, it does cause a new issue when using IE8. This is because IE is still defaulting to a browser mode of Compatibility View. The issue that is still seen is when searching for issues, the issue list has columns which are extremely wide so therefore very difficult to find the correct issue.

          I think this all has to do with the way Microsoft controls it's compatibility view settings. According to a non-microsoft site at http://hsivonen.iki.fi/doctype/, in the section named "IE8 and IE9 Complications" it says that IE uses doctype sniffing like other browsers only if the site is NOT in the Intranet zone. However, when accessing any site via a short name (netbios), such as http://jira, IE places that site in the Intranet Zone, and therefore enables Compatibility View which therefore changes the way IE displays the page.

          So far, I have not found a solution to that besides convincing the domain administrators to implement a group policy change which will turn off compatibility view for all intranet sites. However, this could cause issues with other sites which may be legacy sites on our network, so they are very hesitant to make such a change.

          Unless Atlassian has any pull with Microsoft to have them change the way they handle their Compatibility View mode in IE, the group policy change seems to be the only solution.

          Also, turning off compatibility view for Intranet zone sites with group policy resolves all issues and the extra meta tag isn't even needed since IE then follows HTML standards and uses the doctype html tag to tell it to use HTML5 encoding.

          Show
          Adam Barylak added a comment - We were able to find a partial solution to this issue. By adding the following code to both header.jsp and header-deprecated.jsp files in the includes\decorators folder we are able to enable the correct Document Mode. <meta http-equiv="X-UA-Compatible" content="IE=edge" /> However, that code needs to be the first thing after the <head> tag in both those files in order to take effect. Apparently the 'edge' value is not recommended for production use, but it seems to fix a lot of the issues. However, it does cause a new issue when using IE8. This is because IE is still defaulting to a browser mode of Compatibility View. The issue that is still seen is when searching for issues, the issue list has columns which are extremely wide so therefore very difficult to find the correct issue. I think this all has to do with the way Microsoft controls it's compatibility view settings. According to a non-microsoft site at http://hsivonen.iki.fi/doctype/ , in the section named "IE8 and IE9 Complications" it says that IE uses doctype sniffing like other browsers only if the site is NOT in the Intranet zone. However, when accessing any site via a short name (netbios), such as http://jira , IE places that site in the Intranet Zone, and therefore enables Compatibility View which therefore changes the way IE displays the page. So far, I have not found a solution to that besides convincing the domain administrators to implement a group policy change which will turn off compatibility view for all intranet sites. However, this could cause issues with other sites which may be legacy sites on our network, so they are very hesitant to make such a change. Unless Atlassian has any pull with Microsoft to have them change the way they handle their Compatibility View mode in IE, the group policy change seems to be the only solution. Also, turning off compatibility view for Intranet zone sites with group policy resolves all issues and the extra meta tag isn't even needed since IE then follows HTML standards and uses the doctype html tag to tell it to use HTML5 encoding.
          Hide
          Robert Smart [Atlassian] added a comment -

          This needs to be done on the 4.4.x branch only. Please use the same meta tag as 5.0. Please Adam Barylak says put the tag as high in the header and header-depreciated.jsp as possible.

          Show
          Robert Smart [Atlassian] added a comment - This needs to be done on the 4.4.x branch only. Please use the same meta tag as 5.0. Please Adam Barylak says put the tag as high in the header and header-depreciated.jsp as possible.
          Hide
          Eva added a comment -

          I am also seeing Huge font when accessing Filter page - this happen on IE7 and IE8. What's going on?

          Show
          Eva added a comment - I am also seeing Huge font when accessing Filter page - this happen on IE7 and IE8. What's going on?
          Hide
          Dariusz Kordonski [Atlassian] added a comment -

          Tested in IE9 in Intranet zone. <meta> tag is where should be and dropdowns on view issue look good.

          Show
          Dariusz Kordonski [Atlassian] added a comment - Tested in IE9 in Intranet zone. <meta> tag is where should be and dropdowns on view issue look good.

            People

            • Assignee:
              Unassigned
              Reporter:
              Michael Andreacchio [Atlassian]
            • Votes:
              18 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: