Bug #76166
closed
Set X-UA-Compatible in ModuleTemplate for frontend editing
100%
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.
Updated by Wouter Wolters almost 8 years ago
Can't you set the following header in the .htaccess?
Header set X-UA-Compatible "IE=edge"
Updated by Christian Weiske almost 8 years ago
I can try that, or better the setting that's correct for nginx.
But that would only help me, and not others.
Updated by Wouter Wolters almost 8 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).
Updated by Christian Weiske almost 8 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.
Updated by Riccardo De Contardi over 6 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.
Updated by Christian Weiske over 6 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.
Updated by Riccardo De Contardi over 6 years ago
- Status changed from Needs Feedback to New
Updated by Gerrit Code Review over 5 years 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
Updated by Susanne Moog over 5 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 9b222cebcedc31690c3a8666a8f8d0980b92a020.
Updated by Benni Mack almost 5 years ago
- Status changed from Resolved to Closed