Ubuntu

Problems with framesets

Reported by Christian Schürer-Waldheim on 2008-03-14
6
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
Medium
firefox-3.0 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: firefox-3.0

In firefox-3 (beta 3 and 4) I experience a problem with framesets.

E.g., if I open the admin page of typo3 (3.8.1) on some server and select "page", then the page tree isn't opened in the right frame as it should, but it is opened in the same window.

I have a similar frameset problem with some version of phpmyadmin (2.6.1). If I want to browse the table of some database, then the page isn't opened in the right frame, but as a separate window/tab. This problem doesn't occur with phpmyadmin 2.9.1.1.

But as both webpages (typo3 and phpmyadmin) worked without any problem in firefox-2, I think this is a problem with firefox-3.

Is anyone else having this kind of problems?

Created attachment 304703
Correct display in beta 2

Created attachment 304705
Incorrect behaviour in beta 3 and nightly

This is broken since 2008-01-30 nightly build. 2008-01-29 build still works.

This problem is also covered int he typo3 bugtracker under the folowing ids:
http://bugs.typo3.org/view.php?id=7516 (Typo3 4.2)
http://bugs.typo3.org/view.php?id=7646 (Pre Typo3 4.2)

Beginning from 2008-01-30 nightly switching to a module after login to the Typo3 backend triggers a JavaScript error:
"top.fsMod is undefined"

Binary package hint: firefox-3.0

In firefox-3 (beta 3 and 4) I experience a problem with framesets.

E.g., if I open the admin page of typo3 (3.8.1) on some server and select "page", then the page tree isn't opened in the right frame as it should, but it is opened in the same window.

I have a similar frameset problem with some version of phpmyadmin (2.6.1). If I want to browse the table of some database, then the page isn't opened in the right frame, but as a separate window/tab. This problem doesn't occur with phpmyadmin 2.9.1.1.

But as both webpages (typo3 and phpmyadmin) worked without any problem in firefox-2, I think this is a problem with firefox-3.

Is anyone else having this kind of problems?

Still broken in beta 4.

See this bug report http://bugs.typo3.org/view.php?id=7646 for some discussion about this problem.

Changed in firefox:
status: Unknown → New

The problem is typo3 uses a frameset which has a frame with the name = "content", and in js references that frame via top.content, which doesn't work - instead, top.frames[framenumber] works (in the case of typo3 std. install its top.frames[3]) - so this really isn't an issue of typo3 itself, but of the ff3 js engine - replacing this code parts of course "fixes" the problem, but i don't think that's the way to go, as i wouldn't love to add another browser to my list of "can't do x in js" for webdeveloping

Irina Oltu (i-gen) wrote :

I have exactly the same problem.

Pedro Villavicencio (pedro) wrote :

thanks for linking it.

Changed in firefox-3.0:
status: New → Triaged
assignee: nobody → asac

Still broken in beta 5.

I have the same problem after upgrading from Ubuntu 7.10 to 8.04, where FF3 is the new default browser. I have had to downgrade to FF2 again with many problems (extensions doesn't work any more, etc.), to work with typo3...

I have the same problem as MarkusD. When will this be fixed? It's really annoying...

You can upgrade Typo3 to 4.2 or have a look in the Typo3 bug list http://bugs.typo3.org/view.php?id=7646 there are patches to solve the problem - I'd think it won't be patched here (firefox) at least not if Typo3 is the only web app which has this sort of problem.

In , Dao (dao) wrote :

*** Bug 431815 has been marked as a duplicate of this bug. ***

Changed in firefox:
status: New → Confirmed

In my opinion typo3 is a very popular cms so it is worth to think about this high amount of users. I don't really understand why the problem occurs, but it occurs when I am using FF3 instead of FF2. With FF2 it works fine. And if there isn't already a final version of FF3: why do not fix it before launching the final version?

Regression range would be very useful, and also a *minimal* testcase.

Imho quite vital issue. E.g. Fedora 9 now ships with FF3 (beta something) and several people reported being unable to use their Typo3 v4.1.x-backend with that.

Although Typo3 implemented a workaround in Typo3 v4.2.0, I don think that's an ideal basis for discussion ...

In an operational environment you can't simply update from typo3 4.1.x to 4.2.x. There have to be some tests, etc. that everything works with the new release (e.g. the used extensions, etc.). It's a major realease with many changes. So e.g. for me its not a solution to simply update to 4.2. Our servers are still working with 4.1.6

What <email address hidden> writes is correct, most big sites will not update to 4.2 for a while. Also, in response to Christian Hernmarck, I think it still is a Firefox problem, as typo3 did not change anything to break it but Firefox developers did change the way code is interpreted and thus should correct it or at least offer a compatibility option...

A *minimal* testcase would be very useful.

(In reply to comment #3)
> This is broken since 2008-01-30 nightly build. 2008-01-29 build still works.
...
> Beginning from 2008-01-30 nightly switching to a module after login to the
> Typo3 backend triggers a JavaScript error:
> "top.fsMod is undefined"
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-01-29&maxdate=2008-01-30&cvsroot=%2Fcvsroot

Not sure what caused this.

I have created a minimal testcase, at http://www.martinseebach.dk/firefox-bug-418807-testcase/

It turns out that the bug is not related to the usage of the name "content", but rather that TYPO3 has immediately executed JavaScript that references top.content before the frameset in the file.

I assume that top.content is then initialized to some value, which the later addition of the frameset isn't allowed to override.

Using the testcase and FF3 RC2 I noticed a strange thing: As soon as I open a new tab in firefox and switch back to teh testcase the bug dissapears. If I then reload the page with the testcase it there again, open new tab, bug vanishes etc.

Logging in typo3 with FF3 RC2 or RC3 the clicking on page I get the error. Then clicking on the back-button of the browser and clicking on page again, everything is alright.

After installing the add on firebug to FF the above "workaround" doesn't work anymore.

This bug is still in Firefox/3.0.1 and is very annoying, as it doesn't only happen with Typo3 framesets. Even the workaround doesn't work anymore. Please, fix this bug in FF, as it worked before. Thx!

Changed in firefox:
importance: Unknown → Medium
Alexander Sack (asac) on 2011-01-06
Changed in firefox-3.0 (Ubuntu):
assignee: Alexander Sack (asac) → Chris Coulson (chrisccoulson)
Martin Pitt (pitti) on 2011-02-15
Changed in firefox-3.0 (Ubuntu):
assignee: Chris Coulson (chrisccoulson) → nobody

The bugs on TYPO3 website appears as fixed.
Can someone please confirm that the issue doesn't reproduce on latest Firefox version? Thank you

lol - 5 years later...
Yes it was fixed in Version 4.1.7 on 2008-06-11.
Since TYPO3 version 4.1 is really old now I don't think that someone still uses it - and even if version 4.1 is in use, then it should be updated to the latest release: 4.1.14 (dated july 2010).

So - if someone is willing to install an old TYPO3 4.1.6 (or older) and test it... please do...

Thanks Christian!
I'm removing the qawanted keyword and close this as RWFM.

Changed in firefox:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.