TYPO3 Core

Could be related to / duplicate of #20757 - maybe you have the chance to reproduce?

changing the browser compatibility version did not work for the customer.

we are verifying their network and pc setup currently, ill keep you updated on the state.

Is he using a dial-up connection with a short timeout?
T-Com router have a senseless short connection timeout time of a few minutes.
Especially this sounds reasonable for "or while trying to edit content elements on a page.", if he needs 10min to write his text or grabs a coffee in between.

he is on a "stand-line", its a bigger company...

Then probably the company goes out through multiple IPs (proxy) and the backend is fixed for a session on a single IP. Analyse your Webserver logs if you see the same session coming from two different IPs, it is not a bug, but a setting you can make:
$TYPO3_CONF_VARS['BE']['lockIP'] = '3';

Sorry to say, but our customer said, that the Setting of Ernesto Baschny isnt helping either.

command back, the fix from ernesto could be working, the point is, the customer had forgotten to logout/login before answering.

we will see if that continues to work.

nope, still no go, the customer still has the problem.

additional information: the problem seems to be internet explorer 8 specific.

I had two clients in my last training, which used IE8 and were sometimes thrown out of backend. We added the site to the trusted sites and think then only one was thrown out once.

I just tried IE8 and got quite quick thrown out, with the hint that IE switched to compatibility mode.. but as I'm now in this, it shouldn't throw me out again (question: why switches IE8 to compatibility mode??).

I'll try to use IE8 the next days to test it a bit.

I tested some minutes with IE8 and couldn't reproduce that.

I was only "thrown out" of the backend as soon as I clicked on that "compatibility mode" icon that is being displayed besides the address bar. Maybe people are just hitting this button thinking that it will reload the page? The reload button is just on side of that. See screenshot.

Why the "compatibility button" resets the session I don't know, but you might try to simply tell people not to hit that button?

No, they for sure didn't hit that button.

I always get switched to Comp-mode, as soon as I open the page properties using the click-menu in the page tree.

I think it's a new session b/c a IE7 is loaded internally (which seems not to share the session data).

I found no way to get an error log shown and the developer tools weren't modernized since ages. Anybody an idea, how to get information, why IE switches?

It has been documented on how to get rid of the "compatibility switch" on a website. Read the full blown explanation and history of it here: http://www.alistapart.com/articles/beyonddoctype/

To sum up, if we add this header:
<meta http-equiv="X-UA-Compatible" content="IE=8" />

we are saying "IE8 in standards mode please" and then no switch is presented to the user anymore. See attached patch which adds this and try it out.

Okay, will try it after tomorrows exam and appropriate party :)

I think then I should at least get error messages, what IE doesn't like.

IE8 displays that buttoon on every page that is presenting itself in standards mode and has no meta-tag. This is not an error message, but the intended behaviour (allowing the user to switch the mode when the page author hasn't really specifying the target browser).

If you are not used to see this toolbar icon it is because most major sites either already have this meta tag "X-UA-Compatible" in their headers (facebook, web.de, spiegel.de etc) or they have no indication of wanting standards mode (e.g. invalid xhtml, no DOCTYPE, etc).

Since TYPO3 presents itself as "standards valid xhtml" but doesn't say which IE version it targets, that IE7-compatibility button is shown.

Adding the meta-tag will solve the problem.

If your Backend is switching back and forth the IE8 + IE7-mode, it might come from extensions that provide invalid markup or something that makes IE switch a sub-frame into quirck mode. That is just an assumption, don't know if this is really the problem.

And another note about this, just found this piece of information, which might explain why setting the TYPO3 backend in the "trusted" zone alleviates the problem:

"A large number of line-of-business websites are Internet Explorer 7 capable today. In order to preserve compatibility, Internet Explorer 8 ships with smart defaults based on zone evaluation. In the default state, all sites on the public internet display in Internet Explorer 8 Standards mode (Compatibility View off) and all intranet websites display in Internet Explorer 7 Standards mode (Compatibility View on). "

from http://blogs.msdn.com/ie/archive/2008/08/27/introducing-compatibility-view.aspx

No, has nothing to do with extensions. I only opened Backend and a TCEform.

There should be a reason, why it falls back to IE7, I hope this triggers an error message, if we state that it shouldn't fall back.

Will try it locally soon...

thank you very much for checking this up.

adding the new meta tag indeed fixed the problem for the customer it seems.

the patch of course is not for the current 4.1, i think this is 4.2 code, however, i put in the code myself by hand, and the customer has not yet been logged off.

Yes, I had only a few tests but got not logged out.
Although I'm very unhappy with adding such browser-specific bullshit, I'd say it would avoid headache of several TYPO3 admins.

added 4.1.13 patch.

As from my observation, I can confirm that X-UA-Compatible meta tag solves a lot (all?) of the problems for logins getting invalid... so a +1 for introducing this for the moment (hopefully IE >= 9 won't choke on this one).

Maybe it would be a good idea to have some extra config option for the frontend (ie tslib_pagegen) as well, since as for the moment the only thing that works without hacking the core is to set
config.headerComment (
-->
<meta http-equiv="X-UA-Compatible" content="IE=8" />
<!--
)
since IE8 expects the meta tag at the very beginning of the page.
But this is another topic of course.

ok, this is getting weird.

user confirms the bugfix didnt work.

he has been logged of 2 times within the last 3 minutes.

This confirms my experience that IE tries it first with "standard" mode and then falls back to Compatibility mode. This causes the logout.
Afterwards IE never switched back to the IE8 mode but stays with compatibility mode.

i have now added a global setting, that might fix this for now to my htaccess

#enable ie compatibility mode
Header set X-UA-Compatible "IE=EmulateIE7"

no information on that one yet from the customer, so we will see...

oliver so this fixed the problem or not? In note 31924 you said the bugfix "didnt work".

the bug is not fixed yet.

the user has not confirmed me that the change solves his problem, currently i am in wait state, as soon as i know more, i will inform you.

on a side note, adding the htaccess information seems to break other parts of the homepage, namely kj_imagelightbox

Why don't you set the compatibility mode to IE=8? TYPO3 shouldn't cause problems with this.

setting compatibility mode in ie8 worked for the backend, but if he (the customer) sets that, lightbox in frontend causes javascript errors (browserhangs, debugger wants to open...)

the idea behind setting the htaccess value was, that customer doesnt have to change things in his/her ie8, and the page itself decides.

the customer is not the kind of person, that knows howto use a webbrowser.

command back, the ie8 compatibility fix seems to work.
the lightbox isnt broken either, customer usage error...

the thing seems to work in general.

logouts do happen in IE8 with current 4.3 trunk as well

i.e After logging in a click on an click menu icon in the page tree and then on "edit" lead to a logout
After logging in a second time the same procedure worked without logout
Seems there is a problem with session handling between different URLs in frames or something like that.

Please read my comments above. This is because it first tries the IE8 mode and then falls back to IE7. I had the exactly same test procedure.

Please try to add
Header set X-UA-Compatible "IE=8"
to your .htaccess file

(of course, this doesn't explain, WHY it falls back to compatibility mode)

Maybe better test the ie8-force-strict.diff patch, which is what we would need to add to the core instead of a .htaccess switch which might affect much more than just the TYPO3 backend.

@JoH, could you test it, please? I couldn't reproduce it, yet.. :(

Thanks for the hint, Ernesto! Didn't see the new patch. Just knew that the old one was not that nice. Will try it, too.

Edit: I see, the new patch is the bad one :-[

Steffen, could you be more "precise"? What is bad about this patch?

I cannot really follow your arguments as I am not sure where you are guessing, proposing a solution that might work, or provide a working solution. Do you know how to solve the problem already?

What I can say is that with this patch the "compatibility switch button" is gone unter IE8 and TYPO3 backend. If this avois the logoff problem or is just of cosmetical nature, either way I think it is "good", as the compatibility switch button in IE8 being present in TYPO3 backend is already ugly.

Sorry, I'm a bit harried today...

I remembered template.php.ie8_backend_logoff.diff, which is not a unified diff.

I can't reproduce the frequent logouts as they appear for oliver's client: As Jo, I login, do sth. and then get logged out, because IE switches to compatibility mode (=IE7).
IE7/8 seem to not share their cookie information, so the session is ended and user logged out.

If I force to use IE8-mode, everything worked for me. I hoped to find out, WHY IE switches, but couldn't find anything (thought of a JS error.. but nothing). So it seems to stay a mistery.

As IE8 mode seems not to have any problems with TYPO3 BE, I also think we should add the meta tag to TYPO3.

Of course, my advise to add the line to .htaccess was ment for testing purposes (and could also be added typo3/.htaccess :-P).

As you provided a patch for 4.3, I'd appreciate to have this and a 4.2 compatible one in core list.

Hope you understand my weird notions now :)

The problem is that these logouts really happened randomly, so it is not easy to reproduce them with or without an active compatibility mode.

The only thing I can confirm is, that switching the mode manually will log you out immediately.

Adding a META tag could break stuff in other versions of IE though.

@JoH, "could break" what do you mean exactly? Previous version of IE didn't care (didn't even know) about this meta tag, future versions of IE will know that we aimed IE8 and act acordingly. So I see no problem whatsoever of backwards compatibility issues with this meta tag (which is why it was introduced in the first place).

If you run your system with my mentioned patch and it doesn't logout, it might be the solution and we should / could /must also apply this to TYPO3 v4.2 and v4.1.

@Steffen, thanks for explaining. still you haven't said if you think ie8-force-strict.diff "bad" or "good". It is unified, and yes, it is for trunk only (because it is still unproven that this is really related to the "logoff" problem). Attached is now also a patch for 4.2.

Now I got one I was able to reproduce:

1. Login without activated compatibility mode
2. Go to Extension Manager
3. Switch to "Import Extensions"
3.a) If the Extension Manager already shows "Import Extensions" switch to "Install Extensions" and back to "Import Extensions"

This will always trigger the compatibility mode and logout immediately.

Well - even this one seems to be randomly working: Now i's the other way around and it kicks me when switching to "Install Extension"

@JoH, not reproduceable here with 4.2.10.

I've had one "logoff" already but also cannot say what exactly was done (just switching from Page to List view as far as I remember). Very difficult to spot!

Maybe you could find something out if you really got it reproduceable on your system. Maybe try the ie-force-strict-42.diff patch to see if it helps?

I am talking about 4.3beta3 here not 4.2 :-)

the error is reproducable here, an the interesting thing about it is, that the site is added to the list of sites to be shown in compatibility mode as well. Which will lead to the site being shown in compatibility mode automatically at the next visit.

@Ernesto
I call it "bad" because i think the way it is done, is bad. I haven't tried it, as I didn't know, to which version it applies.

@Jo
Can you reproduce the problem with the patch applied? I think it doesn't switch, if the header/meta is present and so it should work.

Also it can't break any older version. For newer versions, the setting has to be adjusted. Back like in times of browser switches. Thanks M$.

I guess the bad guy is this one:

onchange="jumpToUrl('index.php?&id=0&SET[function]='+this.options[this.selectedIndex].value,this);"

With the meta tag the switch doesn't happen anymore, but IMHO this just removes the symptom but not the cause.

So maybe we should better tryto find out what causes IE8 to switch.

@Steffen, what is "bad" about the way it is done? Can you suggest something better?

The MS-idea is that it doesn't need to be adjusted in newer versions. Newer versions of IE will know how to behave. It is like our good old "compatVersion" in TYPO3, which we added for the exact same purpose: make the rendering of a newer version "behave" like an older version. So I see no flaw in the concept and it is much better than the previous fixes (switching xml-prologue etc). This was created in a collaboration of many CSS / XHTML specialists and MS. See http://www.alistapart.com/articles/beyonddoctype/

So maybe you are just biased by previous MS-oddities which might mislead your judgement on the matter.

For our TYPO3 backend it should mean:

If we know that our backend works in IE8, we "tag" it as such in this meta tag and also future IE versions will know about it without "breaking" our site. Because IE8 can also emulate IE7, we might even tag ourselves for IE7 so IE8 will know about it.

After all it seems I found the reason, why in the case I was able to reproduce IE8 switched to compatibility mode:

The reason is the badly formatted URL handed over to the JavaScript function jumpToUrl.

After replacing any & with &amp; before using window.location.href, the switch didn't happen anymore.

URL = URL.replace(/&/g,"&amp;");

Since this removes a cause instead of the symptom, IMHO we should check if this could be a cause at other places as well.

Maybe the URL has to be formatted according to the doctype to avoid the switch? Then we will need an additional check. But first I would like you guys to check if you can confirm my observations

It's getting weirder: The stuff I mentioned in my last post stopped working. Now it seems that every second call of a window.location.href causes the switch.

Have to investigate further.

Internet Options> Advanced> Browsing> uncheck "Automatically recover from page layout errors with Compatibility View."

This does prevent IE8 from switching to IE7 mode - but this means: There must be "page layout errors" recognized by IE8 that trigger this behaviour, which still leaves us with the problem that we have to find the cause.

Sorry, but again the question: Does IE switch to compatibilty mode, if the X-UA-Compatible flag is set? Regardless of finding reasons for the switch, we have to add this flag because I'm 99% sure, we'll never find all the reasons, why it switches.

@Ernesto
I hate this flag because as we see here, it results in trouble. Why does it not just act as IE8 and work closer to the standards and enough.

hmpf - what a strange topic.

Maybe the reason is something totally different. Could it be that IE switch to compatibility mode if the HTML isn't valid? Mybe not "invalid" but having not allowed nested elements or unclosed tags.

Check #21511

I've just dealt with a similar issue with a client of ours.
The problem, in our case, occured even between updates of IE (7->8).
Spent numerous of hours trying to figure it out and trying to replicate the issue and here's the deal:

For some reason Google Chrome Frame was installed and although it should not interfere unless told so specifically through <head> it does. It breaks IE7/8 (confirmed) and possibly IE6 aswell.

Should mention that the session timeout/random logoff occurs as soon as an AJAX-call is made.

Committed to svn
4_3 rev 6759
trunk rev 6760
4_2 rev 6761