Project

General

Profile

Actions

Bug #21511

closed

Lots of HTML, JS and/or CSS errors force IE8 to switch to compatibility view

Added by Jo Hasenau over 14 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
-
Target version:
-
Start date:
2009-11-09
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

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>

The full story: http://blogs.msdn.com/ie/archive/2009/02/16/just-the-facts-recap-of-compatibility-view.aspx

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)


Related issues 11 (0 open11 closed)

Related to TYPO3 Core - Bug #21518: Unescaped & in urls of list moduleClosedSteffen Kamper2009-11-10

Actions
Related to TYPO3 Core - Bug #21520: Clean markup in Extension ManagerClosedSteffen Kamper2009-11-10

Actions
Related to TYPO3 Core - Bug #21521: t3lib_div::linkThisScript isn't xhtml compatibelRejectedSteffen Kamper2009-11-10

Actions
Related to TYPO3 Core - Bug #21524: opendocs produce invalid HTMLClosedSteffen Kamper2009-11-10

Actions
Related to TYPO3 Core - Bug #17666: be sessions time out before $TYPO3_CONF_VARS["BE"]["sessionTimeout"]Closed2007-10-10

Actions
Related to TYPO3 Core - Bug #20757: Session Timeout after BE Login IE8ClosedSteffen Gebert2009-07-15

Actions
Related to TYPO3 Core - Bug #19883: timout after backend login in 4.2.4ClosedChristian Kuhn2009-01-21

Actions
Related to TYPO3 Core - Bug #22573: opendocs can cause duplicate id html errorsClosedSteffen Kamper2010-05-03

Actions
Related to TYPO3 Core - Bug #20216: Add xmlns attribute to html tag in backendClosedChristian Kuhn2009-03-20

Actions
Related to TYPO3 Core - Bug #20334: XML prologue always after doctype declaration in BE template buildingClosedPatrick Broens2009-04-22

Actions
Has duplicate TYPO3 Core - Bug #21070: session-timedoutClosedChristian Kuhn2009-09-16

Actions
Actions

Also available in: Atom PDF