TYPO3 Core

How it looks like on my computer : see attached files.

No idea if it may help to find out the bug but some reading about "frame" in Firefox 3 leads me to this page :

http://developer.mozilla.org/en/docs/Updating_web_applications_for_Firefox_3#HTML_changes

Let see if the Firefox 3 beta 4 resolves the bug
http://developer.mozilla.org/devnews/index.php/2008/02/26/firefox-3-beta-4-starts-baking-tonight/

This bug started with Firefox (Minefield) nightly build 2008-01-30, the build from 2008-01-29 is ok. This is also covered in this Firefox bug report: 418807 - "Typo3 frameset is not working properly anymore" (https://bugzilla.mozilla.org/show_bug.cgi?id=418807), but it isn't acknowledged yet.

At first I suspected the following Firefox bugfix: 408052 - "Adopt "ancestor" frame navigation policy to prevent frame hijacking" (https://bugzilla.mozilla.org/show_bug.cgi?id=408052) - but it was already integrated on 2008-01-27 into the Firefox latest trunk.

There were quite a lot of changes to Firefox from 2008-01-29 to 2008-01-30, so I couldn't find a hint skimming through the changelog (http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&date=explicit&mindate=2008-01-29+04%3A00&maxdate=2008-01-30+04%3A00)

Hopefully this gets fixed inside Firefox, as patching a lot of older T3 installs would be cumbersome.

fixed the issue with v. 4.1.5:

typo3/alt_menu_functions.inc:

line 333: change
[code]
top.content.location=top.TS.PATH_typo3+(
top.nextLoadModuleUrl?
"'.($prefix?$this->wrapLinkWithAB($link).'&exScript=':'').'listframe_loader.php":
"'.$this->wrapLinkWithAB($link).'"'.$addJS.'+additionalGetVariables
[/code] );

to
[code]
top.frames³.location=top.TS.PATH_typo3+(
top.nextLoadModuleUrl?
"'.($prefix?$this->wrapLinkWithAB($link).'&exScript=':'').'listframe_loader.php":
"'.$this->wrapLinkWithAB($link).'"'.$addJS.'+additionalGetVariables
);
[/code]

i did it with
[code]
if (top.content != top.frames³) {
top.frames³.location=top.TS.PATH_typo3+(
top.nextLoadModuleUrl?
"'.($prefix?$this->wrapLinkWithAB($link).'&exScript=':'').'listframe_loader.php":
"'.$this->wrapLinkWithAB($link).'"'.$addJS.'+additionalGetVariables
);
} else {
top.content.location=top.TS.PATH_typo3+(
top.nextLoadModuleUrl?
"'.($prefix?$this->wrapLinkWithAB($link).'&exScript=':'').'listframe_loader.php":
"'.$this->wrapLinkWithAB($link).'"'.$addJS.'+additionalGetVariables
);
}

[/code]

but i think the above is sufficient

I just tried your patch in several browsers and it works quite well, actually.

It doesn't work at all if you set the navigation mode in the user settinges to "icons in the top frame". Maybe it's because I use the extension "skin_grey_2", but i guess it's not.

the code i posted above doesn't fix every part of the problem, it only fixes the issue for the std typo3 things - but if you look around the line i posted in typo3/alt_menu_functions.inc, then you will see more lines containing top.content.... which also has to be treated the same way, eg. replaced with top.frames³ - actually the real problem with this solution is, if the frameset would change and a frame was added or remove before the content frame, that wouldn't work anymore, as top.frames[x] uses the number of the frame while top.content uses the name, so while top.frames[x] works in ff3, top.content is actually the better way, but i haven't yet found another way to fix the issue, so for now, just replace the occurrences of top.content with top.frames³ and you should be ready to go with ff3.

FireFox 3 Beta 4 still has the problem, can confirm it.

...and my code changes still "fix" the problem - also tested them with different browsers (ie 6 & 7, safari 2 & 3, ff 2 and of course the here accused ff 3) and couldn't find anything which stopped working after changeing the code in that manner.

For now im changeing these parts in all our typo3 installations via automated replace and i'm starting to get the impression, that there is no real reason to use top.content instead of top.frames³, except for flexibility for possible future changes of the typo3 backend frameset.

Has anyone of you ever changed the frameset or installed something which changed the frameset? If not, i think you could consider replacing top.content with top.frames³ as a permanent fix - another option would be to test if the problem is only with the name "content" and not the frames themself, but i haven't gotten around to test that yet.

Edit: Sorry, didn't get the thing with "icons on the top" when first reading the posts, maybe i'll investigate into that, but my first guess is just that it changes frameorder or adds frames to the frameset which easily could be circumvented by using somethin like

[code]
echo 'virtual_frameset = { content: top.frames["' . $framenumbers['content'] . '"], ...};
[/code]

and then

virtual_frameset.content...

instead of

top.content...

-- don't know about the actual code, but something like that would work and still be somewhat flexible.

FireFox 3 Beta 5 still has the problem, can confirm it.

I guess I'll have to stay with FF2, allthough I'd love to test the new memory behaviour of FF3. Patience you must have, as Yoda would say.

An other solution is to migrate to version 4.2 which works fine with FF3.

I have little hope that the bug is going to be fixed in the final FF3 without patching TYPO3 4.1.

I digged into this issue.
the problem is the name "content" (in top.content....) if you change it (and the name of the frame) to e.g. "content1" then it runs normally.
But it's not only a ff naming bug - it also has to do with the very complex frames and javascripts in typo3...

With the js debugger (Watches), you can see that there is no "top.content" object anymore... well, there is one but it's the toplevel frame (or the actual window - I don't know exactly) and not the frame it was before ff 3.

in the alt_main.php of typo3 4.2 there was a change in the call of the function goToModule (in 4.2 this was moved to the menu-frame and in the alt_main.php there is now a wrapper for this function).

Maybe someone has more infos - I'll try to figure out what's an easy way to get this fixed...

Just a small addendum:
on a first view, it seems you just can use theese three files of typo3 4.2 in the typo3 4.1.6 installation:

typo3/alt_main.php
 typo3/alt_menu.php
 typo3/class.alt_menu_functions.inc

But I did no deeper checks... !!

Hey Christian,

willing to make a patch for 4.0 / 4.1 ?

Would be really helpful!

Hi Benjamin

Sure, I just wait for some others to check/confirm if the solution is just copying theese three files from 4.2 to the older versions...

It seems that some devs noticed the problem and did correction for the old backend but only in version 4.2 - I'm just not sure if it's doen by copying the 3 files...
Feedback from the others here would be great...

I'l make a patch this weekend - but it will look more complex than it is :-)

Hi

I did go through the changes in the already mentioned 3 files and created a patch which should exactly address this problem. See typo3_bug_7646_for_416.patch - this is for Typo3 4.1.6.

It's only a part of Revision 2330 and 2349
http://typo3.svn.sourceforge.net/viewvc/typo3?view=rev&revision=2330
http://typo3.svn.sourceforge.net/viewvc/typo3?view=rev&revision=2349

I don't know if the changes on the other files addressed in 2330 are also important here...

I really hope someone will help to check this through.

Then we could see what's needed for 4.0.8

/Christian

My patch also seems to work with Typo3 4.0.8.

But I still don't know if it covers everything.

So please test it in more special cases.

/Christian

i can confirm that the patch "typo3_bug_7646_for_416.patch" works for me
(typo3 4.1.6 in FF3.0b5 on Linux)

someone should post this in the corelist

Yes, the only concern I have with the patch is that I don't know if it could break anything (as it will go in a stable release, we need to be sure about that).

On https://bugzilla.mozilla.org/show_bug.cgi?id=418807 I just received a comment that this probably won't be fixed in FF3.

So a patch should definately go in the typo3 4.1 and 4.0 trunks, since upgrading to typo3 4.2 may not be an option for many people yet, due to the dependency on PHP5.2 (which is not included in many server distros, e.g. RHEL).

So is it possible that this get's fixed in an official 4.1 release soon?

Would be great if some more "works for me" would appear - more tests... we are not only two who want this patch!!!

Concerning the comment of Benjamin (21732): there were not many changes in theese files in the last years. The changes were done in the trunk about a year ago they should not break anything in Typo3 4.1 - and I think also in Typo3 4.0 this should be ok (I don't know if there will be an official update/patch for Typo3 4.0)....

Ok, here comes another "works for me": I have tried the typo3_bug_7646_for_416.patch on our testsite (typo3 4.1.6), it seems to work just fine. What are the necessary steps to have this included in the next 4.1.x release?

Works for me in default mode (Tested on 4.1.5)...

But like I previously said, it doesn't work in any browser if you set the navigation mode in the user settings to "Icons in the top frame"

@Florian Kuss
your first comment about this was for the first patch... but you're right.

I'll try to get the problem here ASAP...

Please try typo3_bug_7646_for_416_v2.patch there the menu_sel is also changed.

Upd.. or better v3 :-)
then the same problem with "icons in the top menu" is also solved...

V3 seems to work now.

Nice job!

Hi guys! Thanks for the good job and serving the patch. One (maybe silly?) question: how can I patch my typo3-installation that is on a managed server and doesn't gives me ssh/telnet-access, so I cannot use the patch command from the command shell....

you can patch at home and upload the changed files (AFAIK 5 files, all in typo3 folder)...

Just wanted to say that the patch (v3) works fine.
I tried to fix TYPO3 4.1.4 with patchv1 first, but it didn't work properly.
Then I first updated to TYPO3 4.1.6 with patchv1 and experienced the problems with "Icons in top frame/menu". Works fine with patchv3 now. Thanks!!!

Please post this fix in the core list.

In case you need more "works for me".
I tried v3 successfully on 4.1.6

Thanks for the patch

+1 from testing v3 on branch TYPO3_4-1 revision 3652.

There's now also a +1 from a core team member so please feel free and send an RFC to the core list.

This problem has to be solved, FF3 is now already shipped as RC.

More about: http://lists.netfielders.de/pipermail/typo3-team-core/2008-May/016516.html

I sent the RFC!
Please whoever wrote this cool thing: go to corelist, search for the patch and describe what it does! I simply can't do this because of missing knowledge about this patch.
this information is required to get the patch into core!

Hi

I uploaded the patch - but honestly - I don't know exactly what it does :-)

I realized that Typo3 4.2 did not have the problem in the "alt_main" backend and found some bug fixes which exactly solved this problem too.
As I stated in Post 0021297 my patch is more or less the patch to fix the bugs #15084, #15084 and #15084 - which were fixed by Ingo Renner and Oliver Hader.

What can I do? Please put it in the trunk...
corr: not in the trunk, but in the next typo3 4.0.x and 4.1.x versions :-)
Ch

@ christian: please post all infos you got into the thread in core list including the info you gave here now.

Ok, I did... thanx
http://lists.netfielders.de/pipermail/typo3-team-core/2008-May/016537.html

did anybody write a patch for 3.7 ?
(i know it's obsolete but i cabt upgrade to php5).
thanks

hey,

just upgrade to 4.1 then (doesn't require php5 yet).

i wont upgrade just to correct this bug. my typo3 system is stable. i dont want to have to reconfigure it and the extensions. i'd like instead to correct the few javascript lines that needs to be corrected.
my users ar used to this look. perturbing them is not needed.

just FYI: bug still not fixed within FF RC2!

@ le h?naff: 3.7 maybe stable but not secure. you can still apply the patch for your version manually

you mean i can apply the patch for 4.1.6 ( typo3_bug_7646_for_416_v3.patch) on 3.7?

this is really no help forum but a bugtracker, so please don't respond here anymore but yes!

I created a minimal testcase for the Firefox bug in Mozilla's bugzilla, and found that the problem isn't the use of the name content, but that TYPO3 has javascript running before the frameset, which references top.content. I assume that top.content is then initialized to some value, which the later addition of the frameset isn't allowed to override.

http://www.martinseebach.dk/firefox-bug-418807-testcase/

View the source on the two alternatives to see what causes the bug.

TYPO3-specific, the problem is in busy_checkLoginTimeout_timer() which is defined in alt_main.php. In the bottom of that function, is this block:

// Detecting the frameset module navigation frame widths (do this AFTER setting new timeout so that any errors in the code below does not prevent another time to be set!)
                if (top && top.content && top.content.nav_frame && top.content.nav_frame.document && top.content.nav_frame.document.body)       {
                        TS.navFrameWidth = (top.content.nav_frame.document.documentElement && top.content.nav_frame.document.documentElement.clientWidth) ? top.content.nav_frame.document.documentElement.clie
ntWidth : top.content.nav_frame.document.body.clientWidth;
                }

which, as I can determine, is the culprit. Commenting it also solves the problem, but I assume that it does something useful, so that's not a permanent solution.

To solve it (tested on 3.8.0 and 4.1.5):

In alt_main.php, find this:
/** * Initialize login expiration warning object
*/
var busy = new busy();
busy.loginRefreshed();
busy_checkLoginTimeout_timer();

Change that last line to:
window.setTimeout("busy_checkLoginTimeout_timer();", 10000);

Regards,
Martin Seebach

i confirm this tweak works on 3.7.
thank you martin

ff3_t41.diff works fine on my test system without backporting all the stuff from 4.2, please test!

Martin, your tweak appears to work but I'm experiencing another problem that may or may not be related to this. When I insert your tweak to alt_main.php the RTE doesn't work. Sadly I don't know of a quick way to test the RTE without your tweak since then I can't access any content elements from FF3. So I don't know if the RTE bug was already there but unnoticed, or if your tweak causes it. I tested this on 4.1.2 and 4.1.5 today.

The 4.2.0 issue is marked 'resolved' so I can't add anymore notes there. I've noticed that after I upgrade a 4.1.2 install to 4.2.0 the RTE doesn't work properly either. When I open a text element for editing, the RTE field doesn't show the RTE but just the source code for the content. When I click the checkbox for disabling the RTE, I get the 'login probably expired' warning but nothing happens to the RTE. The RTE only functions when I click the full-screen RTE button next to the text area.

Bas - I don't think it's related. All my tweak does it to delay the initialization of the "keep-session-alive" code slightly. It should be completely seperated from the RTE.

Also, the RTE on my 3.8.0 (only IE) and 4.1.5 (IE and FF3) works fine..

The 4.1.5 -> 4.2.0 issue might be a cache problem, but it's incredible off-topic for this bug ;)

Martin,

I can confirm that in 4.1.5, if I use the window.setTimeout("busy_checkLoginTimeout_timer();", 10000); fix, the RTE becomes unusable within FF3 RC2 after clearing cache, etc. The RTE loads, but it is impossible to click within the text area and type anything.

After reverting and clearing cache, the RTE is enabled again, but the initial problem with frames reoccurs.

Kevin L.

Ok, scratch that.

Apparently this is another error.

Basically, I enabled your change, opened a prepopulated content item with RTE. The RTE did not show the contents of the element, nor does it allow me to type anything within the RTE content item. I then click the "<>" (Show Code) button and it shows me the HTML markup of the content item. I then click the "<>" (Hide Code) button and it shows me the actual RTE content and allows me to edit it.

I have verified that this is the case regardless of whether I use your markup or not. Again, this is 4.1.5 using FF3 RC2 on Mac OS X 10.5.3.

Kevin, what you describe is solved in Bug # 8346: http://bugs.typo3.org/view.php?id=8346

fixed in branches 4.0 and 4.1