Bug #76166
closed
Set X-UA-Compatible in ModuleTemplate for frontend editing
Added by Christian Weiske about 8 years ago.
Updated about 5 years ago.
Category:
Backend User Interface
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.
Can't you set the following header in the .htaccess?
Header set X-UA-Compatible "IE=edge"
I can try that, or better the setting that's correct for nginx.
But that would only help me, and not others.
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).
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.
- 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.
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.
- Status changed from Needs Feedback to New
- Sprint Focus set to On Location Sprint
- Status changed from New to Under Review
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by