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 #1

Updated by Jo Hasenau over 14 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.

Actions #2

Updated by Rupert Germann over 14 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.

Actions #3

Updated by Jo Hasenau over 14 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>)

Actions #4

Updated by Steffen Kamper over 14 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.

Actions #5

Updated by Jo Hasenau over 14 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?

Actions #6

Updated by Steffen Kamper over 14 years ago

i contact Benni on skype and stick him to this.

Actions #7

Updated by Maik Matthias over 14 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.

Actions #8

Updated by Alex Dangel over 14 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.

Actions #9

Updated by Chris topher about 14 years ago

I recently had to use TYPO3 in IE8 and those "random" logouts make TYPO3 nearly unusable.

Considering the market share of IE this really should be improved quickly!

Actions #10

Updated by Robert Wander about 14 years ago

I also have the problems with the random Loggout with my FE-Sessions...

Actions #11

Updated by Steffen Gebert about 14 years ago

#21065 (which is a duplicate of this) is already pending in core list and has enough +1s to be committed

Actions #12

Updated by Jo Hasenau about 14 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.

Actions #13

Updated by Steffen Gebert about 14 years ago

Okay Joey, I removed the relationship again.

For us developers, I admitt that it would be better to see the errors.
But what counts for the users is that their TYPO3 works, and the X-UA-Compatible flag is IMHO (currently) the only possible solution.

Actions #14

Updated by Jo Hasenau about 14 years ago

as long as this won't be the reason to go on as usual ;-)

Just check the trunk of t3uxw final with IEx to get a rough idea of the catastrophe we are heading for.

Actions #15

Updated by Steffen Gebert about 14 years ago

Hehe.. I think we all know that there's still a LOT to do to get our T3UXW work in ;-)

Actions #16

Updated by Jo Hasenau about 14 years ago

BTW: Especially developers of so called "Enteprise" CMSs should take care about MS products, since many of those enterprise clients rely on them.

Actions #17

Updated by oliver leitner about 14 years ago

hello everyone

thx for the info that this was fixed in 4.3

will there be a fix for 4.2?

greetings

Actions #18

Updated by Maik Matthias about 14 years ago

Hi Olli,

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" />

that´s all.

Actions #19

Updated by Steffen Gebert about 14 years ago

#21065 has also been committed to 4-2, so the X-UA-Compatible tag is also in 4.2.11

Actions #20

Updated by oliver leitner about 14 years ago

err, what i ment... since there was a link here from the following bugreport by me: 12901

the random sporadic logoffs are gone, thx for that one.

but the 12901 wasnt fixed by that.

Actions #21

Updated by Steffen Gebert about 14 years ago

I think #21783 isn't related to this

Actions #22

Updated by Steffen Gebert over 12 years ago

  • Status changed from New to Closed
  • Target version deleted (0)

Closing this one..

Actions

Also available in: Atom PDF