Lots of HTML, JS and/or CSS errors force IE8 to switch to compatibility view
HTML, CSS and/or JS errors force IE8 to switch the compatibility mode which might lead to other IE8 related bugs listed here.
This is what IEblog tells us about it:
<blockquote>Another case of "smart defaults" is the setting ‘Automatically recover from page layout errors with Compatibility View’. The topic deserves its own deeper handling as a stand-alone blog entry, but I’ll just quickly state here that the setting makes an otherwise completely unusable page usable again. When the IE Layout Engine encounters an unrecoverable error during page processing it shows a blank page rather than allowing the user to interact with a corrupt or otherwise obviously incorrectly displayed page. In such a case, IE attempts to reload the page temporarily (read: until you close and re-open IE) in Compatibility View based on the setting mentioned above. We believe that showing a page the way IE7 would have is a better user experience than showing no content at all. We’re working hard to fix known causes of these unrecoverable errors in our layout engine and we get Watson data for the rare occasions when they do happen.<blockquote>
So certain issues may not be IE8-bugs but bugs in the code of the pages delivered by TYPO3 to create the backend.
Trying to validate one of the suspicious pages (i.e. the "Translation Handling" section of the EM) gives us lots of errors (in this case 15 errors in just 216 lines of code) due to misformatted URL parameters and "end tags for element xyz which is not open", which might be the cause for the described behaviour.
Not to mention possible errors in the JS-code that is partly fetched from external files.
Any switch between the different IE8 views will kill the session though, which leads to i.e. the "random logouts" as a final consequence of bad HTML, CSS and/or JS
The compatibility view itself again is the reason for certain flaws in the current backend design, when using IE8.
Just forcing a certain mode by means of the new
<meta http-equiv="X-UA-Compatible" content="IE=8" />
IMHO is a no-go, since it's just removing the symptom while leaving the cause as is. And if IEblog is right, it might even lead to empty pages instead of the expected backend forms. This might be true for other browsers as well, although the problems may be partly caused by the so called "IE hacks", that now get back at us as predicted.
So we must make each page that is generated by the core and/or any sysext validate to avoid any unintended browser behaviour. IMHO a lot of the IE related problems currently listed in the bugtracker could be avoided just by a clean up of the code.
(issue imported from #M12532)
#1 Updated by Jo Hasenau over 10 years ago
Quoting myself: So we must make each page that is generated by the core and/or any sysext validate to avoid any unintended browser behaviour.
This means: First we have to fix the bugs in our own code, then we might find out which are bugs of the different browsers and how to handle them.
#2 Updated by Rupert Germann over 10 years ago
thanks for tracking this down, Joey.
I was able to reproduce the "random" logoff by e.g. opening DB check->Full search or in some modules of the extdeveval extension. "Loaded Extensions" in EM also logged me out. Clicking the "switch compatibility mode" button manually ends the session too.
#3 Updated by Jo Hasenau over 10 years ago
The suspect In EM is the <select> Module Menu, which neither got a <form> as a container nor an action, but a weird onChange jumpToUrl JS behaviour that could have been easily acchieved with a real form and action, some hidden fields and onChange="submit();" instead.
Since this menu is generated by t3lib_befunc I guess it will be responsible for other BE modules as well.
And depending on the selected function there are quite a few end tags for elements which are not open. (i.e. </fieldset>)
#4 Updated by Steffen Kamper over 10 years ago
i start cleaning the HTML. But i'm scared by the nested forms problem, it's a general lack of template::form which start normally at the real beginning of the document and can't be closed in inner divs because of the container structure. Mostly this comes from the search form displayed at the end of the page.
#5 Updated by Jo Hasenau over 10 years ago
Maybe this is one for T3UXW09? I guess validating the HTML output and fixing bad browser behaviour this way can be regarded as a usability improvement.
Since Benni Mack will be in charge as the leader of the developer unit there, maybe he can say something about it. So could you assign this one to him and switch it to "feedback" please?
#7 Updated by Maik Matthias over 10 years ago
I can confirm this behaviour with the 4.3.0 release. IE8 often switches into compatibiltiy mode that forces immediate user logout. This happens by opening some flexforms or popups. A reproducable example: Try to open the browser popup under "templates" -> "include basic templates".
Therefore it´s impossible to use IE8 for backend purposes this time.
#8 Updated by Alex Dangel over 10 years ago
Some more reproducable examples:
1. Ext Manager: select "Check for extension updates", then select "loaded extensions"
2. Klick the Pageicon of any Page in your tree -> select "edit" from the contextmenu
3. DB check: switch from "total pagetree" (and some others) to "Full search"
Some of them don´t happen always, but for sure at the second try.
#12 Updated by Jo Hasenau about 10 years ago
Sorry - but this is not a duplicate - it's not even close to being a duplicate, since 11968 is just removing the symptom of being logged out by forcing IE8 into a certain mode.
This one is about getting errors in HTML, CSS and JS fixed, that are the cause for these symptoms, which is something completely different, since it will force people to use more than just Firefox for development instead of ignoring over 50% of the web users and forcing their browser to accept the errors Firefox doesn't care about.
#18 Updated by Maik Matthias about 10 years ago
I think, the problem isn´t fixed, but version 4.3.1 has now a workaround, which seem to help. I never got these logoffs with older versions (4.1x, 4.2.x).
The workaround is also in latest version 4.2.11. It inserts a new meta-tag in backend pages:
<meta http-equiv="X-UA-Compatible" content="IE=8" />