Bug #76166

Set X-UA-Compatible in ModuleTemplate for frontend editing

Added by Christian Weiske almost 4 years ago. Updated 11 months ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2016-05-12
Due date:
% Done:

100%

TYPO3 Version:
7
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:
On Location Sprint

Description

A customer of us uses Internet Explorer which is configured to use the compatibility mode by default.

The normal TYPO3 backend fixes this in #63150 by setting the IE render mode meta tag

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

This is output in the TYPO3 root frameset page via DocumentTemplate.

In frontend editing, this root frameset - and thus the compat tag - is missing.
When editing content elements or page properties, the layout is broken.


The solution would be to add the render mode tag in ModuleTemplate, too.


Related issues

Related to TYPO3 Core - Task #63150: Set X-UA-Compatible meta tag for BE Closed 2014-11-23
Related to TYPO3 Core - Task #30664: Set X-UA-Compatible to IE=9 for Backend Closed 2011-10-08
Related to TYPO3 Core - Bug #49118: X-UA-Compatible Closed 2013-06-14

Associated revisions

Revision 9b222ceb (diff)
Added by Susanne Moog over 1 year ago

[!!!][TASK] Remove X-UA-Compatible from HTML of backend

Resolves: #76166
Releases: master
Change-Id: I5d36ea2342c18fe08cb5b5c06f123e8cb575849c
Reviewed-on: https://review.typo3.org/58744
Tested-by: TYPO3com <>
Reviewed-by: Joerg Kummer <>
Tested-by: Joerg Kummer <>
Reviewed-by: Jürgen Heym <>
Tested-by: Jürgen Heym <>
Reviewed-by: Nicolai Schirawski <>
Tested-by: Nicolai Schirawski <>
Reviewed-by: Anja Leichsenring <>
Tested-by: Anja Leichsenring <>

History

#1 Updated by Wouter Wolters almost 4 years ago

Can't you set the following header in the .htaccess?

Header set X-UA-Compatible "IE=edge"

#2 Updated by Christian Weiske almost 4 years ago

I can try that, or better the setting that's correct for nginx.

But that would only help me, and not others.

#3 Updated by Wouter Wolters almost 4 years ago

I don't think setting this by default is a good idea.

From http://stackoverflow.com/questions/26346917/why-use-x-ua-compatible-ie-edge-anymore

As David pointed out, outside of a page located in the "Local Intranet" zone, there is very little reason to include <meta http-equiv="X-UA-Compatible" content="IE=edge"> in your webpages, and absolutely no reason to include it in the HTML. (You should follow Microsoft's best practice recommendations and place it in your server config or site headers -- not in the HTML itself -- if you need it).

#4 Updated by Christian Weiske almost 4 years ago

If this is the official stance, then TYPO3 should completely drop this HTML head tag and not have it enabled in one place but not on the other.

#5 Updated by Riccardo De Contardi over 2 years ago

  • Status changed from New to Needs Feedback

A possible solution could be adding it only if you are logged in the backend, that is:

[globalVar = TSFE:beUserLogin = 1]
page.meta.X-UA-Compatible = IE=edge
page.meta.X-UA-Compatible.httpEquivalent = 1
[global]

I also guess that the new frontend editing does not need it at all.

Do you think it is sufficient to consider this issue closed? Thank you.

#6 Updated by Christian Weiske over 2 years ago

No, this issue is not closed. You posted a workaround that one could use after someone already stumbled over this bug.
The correct solution would be to add the fix to TYPO3 itself, so that the bug never appears at all.

#7 Updated by Riccardo De Contardi over 2 years ago

  • Status changed from Needs Feedback to New

#8 Updated by Susanne Moog over 1 year ago

  • Sprint Focus set to On Location Sprint

#9 Updated by Gerrit Code Review over 1 year ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/58744

#10 Updated by Susanne Moog over 1 year ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#11 Updated by Benni Mack 11 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF