TYPO3 Core

Same for me:
Vista Business
Typo3 4.1
FF 2.0.0.3

Well, obviously it's not a TYPO3 issue since it worked with older versions of Firefox.

You can help us by reporting the problem to the Mozilla Devs.

We'll have to find a workaround because all users working with firefox 2 will be updated automatically.

https://bugzilla.mozilla.org/show_bug.cgi?id=374738

It appeared with FF 2.0.0.3 - but it still may be a bug in HTMLArea...

/Chris

I have the same Problem on MAC and PC.
After updating from 2.0.0.2 to 2.0.0.3 the HTMLArea do not work anymore.

I got this error javascript-error:
"editor has no properties"

In the generated rtehtmlarea_.....js file i found this definition:
var editor=RTEarea[editorNumber]["editor"];

Maybe this help's someone.

how i'd like to switch to TinyMCE as default RTE.... i made some experiments.. anybody using it in production?

Found a workaround with the add-on User-agent switching:

The only change one need is to replace the 1.3 in the version string, with e.g. 1.2

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
will be
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.2) Gecko/20070309 Firefox/2.0.0.3

That goes in conjuntion with an line:
HTMLArea.is_wamcom = (HTMLArea.agt.indexOf("wamcom") != -1) || (HTMLArea.is_gecko && (HTMLArea.agt.indexOf("1.3") != -1));
in htmlarea.js on line 85

maybe that is the point where one has to start to change things

I'm working on a TYPO3 4.0.4 installation with an htmlarea V1.4.3 using FireFox 2.0.0.3 and of course i have the same problem. Reported below. Maybe this is helpfull for somebody to find an solution to fix it!?

enableCompressedScripts is set to 0

If I empty all cashes and delete the editors js files in typo3temp too, the editor loads exactly one time. Due to this there occurs an JavaScript Error "this._undoQueue has no properties" in file htmlarea.js, function "HTMLArea.prototype._undoTakeSnapshot = function() ", line this._undoQueue[this._undoPos] = { text: txt, time: curTime };

If I load the editor a second time it hang up while loading.
Due to this there occured an other JS error.

"editor has no properties"
File: htmlarea.js
Function: HTMLArea.generatePlugins = function(editorNumber)
Line 1066: var editor = RTEarea[editorNumber]["editor"];

Solution:
RTEhtmlarea was checking if MacOS Wamcom version 1.3 was the user agent with a indexOf("1.3"). The revision number of Firefox also has 1.3 in it, because of revision number 1.8.1.3. This is now checked if version number has not indexOf(".1.3").

See the patch

Comments:
Thanks to Axel Klarmann for pointing in the right direction.

When testing delete all rtehtmlarea related files in typo3temp directory.

Changing the status to resolved.

Reopening this bug, see user comment in bug 0005279.

@Patrick: Next time please do not close bugs unless they have been successfully committed to SVN. Otherwise it's not possible for users to give feedback...

I have patched both js files without an error and the editor still won't load in FF 2.0.0.3 on Mac OS X

edit: I just tested the patch with FF 2.0.0.3 on Windows Vista and it doesn't work there either.

edit2: OK, blame on me, I did not delete the rtehtmlarea_* files in typo3temp, but due to the fact it said "When testing..." and I wasn't testing, I was serious ;-)
Now RTE works again.

When is the ter version updated? So all without shell access can update there rtehtmlarea?

For the people where the patch didn't work: Did you delete all rtehtmlarea related files in the typo3temp/ folder and clear the browser cache?

In addition to bugreport 5279:

----------------------------------------------------
the patch for issue 5266 is incomplete.

the patch tries to exclude following browser identifier
[code]
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
[/code]
with this line
[code]
HTMLArea.is_wamcom = (HTMLArea.agt.indexOf("wamcom") != -1) || (HTMLArea.is_gecko && HTMLArea.agt.indexOf("1.3") != -1 && HTMLArea.agt.indexOf(".1.3") == -1);
[/code]

this condition will still won't exclude future firefox versions, example:

[code]
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.3) Gecko/20070309 Firefox/2.0.0.3
[/code]

so the same bug will reappear in about half a year.
----------------------------------------------------------------------

This is not the case. This line is excluding FF to be HTMLArea.is_wamcom. The old line made FF seen as wamcom browser version 1.3 because it was looking for the string part "1.3", but it is excluding FF now with the ".1.3" (look at the dot).

This patch keeps working when FF version is 1.9.1.3

Concerning the "HTMLArea.prototype.accessParentElements" note (#0013254):
In fact this is a bug that should be solved by another patch (mostly conerning IRRE), see bug-id #5177. The RFC has been sent to the Core-List one week ago - currently waiting for approval.

in reply to note 13195:
you're right that your patch will work with my counter-example on bug #5279, but you're wrong assuming that your patch is correct.

check this out:
[code]
var str = "Mozilla/5.0 [...]; rv:1.3.0) Gecko[...]Firefox/2.0.0.3".toLowerCase();
var condition = str.indexOf("1.3") != -1 && str.indexOf(".1.3") -1;
alert(condition);
[/code]
... and no, adding another condition like "str.indexOf("1.3.") -1" to the list of identifiers would still not be the proper solution since it only solves the symptom and not the problem itself - that you shouldn't determine "is_wamcom" by checking for parts of version numbers.

in reply to note 13266:

The string "Mozilla/5.0 [...]; rv:1.3.0) Gecko[...]Firefox/2.0.0.3" is a browser based on the WamCom release of mozilla. We are not checking the version number, but the revision number. Mozilla never released revision number 1.3.0 and 1.3.1. These numbers were for the WamCom project which ended somewhere in 2004. Revision number 1.3.0 is a release from the beginning of 2003, 1.3.1 of september the same year. This project came to an end in 2004.

I don't expect Mozilla ever to release revision 1.3, 1.3.0 or 1.3.1 or whatever in this range, when they are already on revision 1.8.1.3. It's the same as M&^%* releasing a new operating system in 2008 and call it Windows 94.

I hope this clears things regarding the WamCom releases and the check on it.

Wouldn't it be easier to check
indexOf("rv:1.3.")
instead of
indexOf("1.3") AND indexOf(".1.3")
?

/ch

in reply to note 13275:

No, sometimes a space is used between rv: and the number, sometimes it's not. And putting a dot at the end will still not see revision 1.3 as WamCom, which is.

Re: 0013255 --

I patched the file, deleted all the contents of the typo3temp/ directory, cleared my browser cache, restarted the browser & logged in again. HTMLArea still does not load. Firefox 2.0.0.3 on Windows XP Pro.

Wait - I take it back. It now appears to work. Sorry about that!

Gack. Now it doesn't work again. Weird...

@Jason: Do you get any JavaScript errors?

I did. Based on those I think I've figured out the issue. It looks like the patch successfully updated the standard htmlarea.js, but it failed to patch the compressed version. When I was getting the regular one it worked fine; when I was getting the compressed one it wasn't. I disabled the compressed version in the config file and now it seems to be stable -- at least on the site whose localconf.php I updated.

Of course I now have a bunch of other sites to fix, but that appears to be a different error -- it's throwing an "editor has no properties" error when it tries to load the RTE, for some reason...

UPDATE: clearing out all the rtehtmlarea* files in the typo3temp/ directory of the affected sites appears to resolve that latter problem.

I used patch.exe from GNU utilities for Win32 (http://unxutils.sourceforge.net/) to apply the diff file. It has patched htmlarea.js, but htmlarea-compressed.js has been rejected.

As Jason, I disabled the compressed version (using the Extension Manager ). After deleting the rtehtmlarea* files in typo3temp/ the editor now works fine.

I also noticed that the patch has a problem with the compressed version - i patched the compressed js file manually and this worked.
The compressed file is only a one liner... in the patch it seems that there are more than one line...
So - we can make a patch for the "normla" file and also give the whole new compressed file as a replacement....

(to patch a one liner doesn't make sense...)

Best would be an extension update!!!

/ch

reply to 0013276:
As you wrote in 0013272 the check is only to detect this WamCom version. Are there also spaces between rv: and the version numer? you wrote "1.3.0 and 1.3.1" so I didn't know there is also an "1.3 "...
When Firefox reaches rv:1.30.something we are running in another problem... or our grand childern.... :-)

Since I dont' know if someone is updating the current rtehtmlarea extensions I did it for version 1.4.3 > 1.4.3a :)
See attached file... T3X_rtehtmlarea-1_4_3a-z-200703251756.t3x
Changed: the two htmlarea(-compressed).js, Changelog and ext_emconf.php (version & md5).

Maybe someone can put this on TER??? (I never did this ...) and create an update for 1.1.5 and 1.5...

/Christian

The patch: T3X_rtehtmlarea-1_4_3a-z-200703251756.t3x

is working at my typo3 installation.

Thanks.

When will it be on TER and when ist there an update for the 1.5.1 dev Version
And what is special about the 1.1.5 Version? It shows up as the newest Version in TER.

I just uploaded a patch that removes the check for WaMCom completely (no updates on that project since 2003, abandoned since 2004). The T3X file is the patched version for easy testing.

REMEMBER to clear typo3temp/* AND your browser cache!

I replaced Patricks patch with a slightly fixed version (removed double ";;" in the compressed version).

Additionally I have uploaded a patch for TYPO3 4.0.x

The extensions doens't work with typo3 4.1.

Is there any patch for htmlarea 1.5-dev ?

Oh well... For sure it does! The attached patch bug_5266.diff is for current SVN which should be equal to TYPO3 4.1.

Please check the following:

- There must be no copy in typo3conf/ext/ or typo3/ext/, otherwise the modification in typo3/sysext/ is void.

- Remove typo3temp/*.js

- Clear your browser cache.

With bug_5266.diff and typo 4.1 with rhtmlarea 1.5-dev it works.

Thanks

I was able to successfully patch rtehemlarea v1.5dev on a TYPO3 4.1 install with "bug_5266.diff" supplied above. However I have been unable to successfully patch version 1.4.3 of the RTE on a TYPO3 instance using the 4.0.4 source.

My understanding from http://bugs.typo3.org/view.php?id=4870 is that both htmlarea-compressed.js and htmlarea.js need to be altered?

When I attempt to apply the diff patch bug_5266_4-0.diff to "htmlarea-compressed.js" (version 1.4.3) I receive the following error:

patching file htmlarea-compressed.js
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file htmlarea-compressed.js.rej
patching file htmlarea.js

reply to (0013323) Lars-Erik Forsberg:

Same here.

The no-wamcom-Patch semms to run through...

I patched it manually - the difference is describd in the former notes...

/ch

I tried both .t3x files on a Firefox 2.0.0.3 and TYPO3 4.1 installation, but both fail.

The Firefox error console reports: "each is not defined". Clicking the error redirects me to the line: "var plugin = eval(plugin);"

IE, both 6 and 7 also fail (what else can you expect).

In reply to note 0013330:
Using a version of RTEhtmlarea that was not made for TYPO3 4.1 will throw errors. The "each" thing comes from the prototype JavaScript framework. This was fixed in TYPO3 4.1 (using RTEhtmlarea 1.5.1 as system extension).

My Xperience: Typo3 3.8. Intalled T3X_rtehtmlarea-1_4_3-z-200703261132.t3x as provided above as sysext.
Deleted all typo3temp files. Cleared all cache (and also my browsercache).

Now the editor loads, but the Window for creating links shows blank content.

:-(

Regarding ~13346 - the extension I uploaded is taken from 4.0.5, most probably it is simply incompatible to TYPO3 3.8.

This may be right. But I can not update to typo3 4.1 immediately, because the system is a little bit more sophisticated set up, than 'normal' typo3 installations.
About 500 BE users, in about 200 groups, with about 250 different 'sites'.
As it is a 3.8, I'm also not able to tell the users, they should use IE, because most of them have already IE7, which breaks with typo3 3.8.0

AND: If it is not compatible with typo3 3.8.0, why isn't it set in ext_emconf.php????

The problem concerning 3.8 is solved by using the patch only (the diff may not work, but i didn't test this). I just removed the line of the browser test containing the test for the wamcom browser. The extension seems to be incompatible 3.8; Updated the files manually and it works for all version i got; 3.8 - 4.0

@Clemens:

my rte 1.4.3 is for Typo3 >= 4.0 (see below) but AFAIK the ExtManager in Typo3 3.8 doesn't care about that...

So, we need a version 1.1.5a - which IMHO should run with Typo3 3.8

'constraints' => array(
                'depends' => array(
                        'cms' => '',
                        'php' => '4.1.0-',
                        'typo3' => '4.0-',
                ),

Regarding TYPO3 3.8: of course new fixed versions will be released for 3.8 as well.

But: the version I attached to this bug is for testing purposes, and as such I just didn't care for 3.8 - which I don't run anymore. So stay cool.

Solved the problem for my customer as follows:

Installed Version 1.3.8 from TER.

Deleted the OR of the is_wamcom Variable.

Worx now. :-)

I know, it's QD but for me it's okay in this special case.

Just uploaded a corrected version for rtehtmlarea 1.5.1dev -> 1.5.1a-dev
for the ones with Typo3 v 4.1.0

Works for me - be sure to clean the browser cache and all typo3temp/htmlara... files

/Christian

Guys, it is rather unhelpful if dozens of people posts patches here that don't really solve the problem. That the patch helps you, does not seem to mean that it will help everyone.
Please do not write that your patch solves the problem if you haven't confirmed it properly. None of the patches I found here seemed to work for me (Firefox Linux 2.0.0.3).

@Christian Lerrahn:
You're almost right. The problem is "solved" (FF 2.0.0.3 and rtehtmlarea don't work together) - I don't know why there are that much patches - it's IMHO much better (and for some people the only way) to upload a new rte extension - the only problem is the cache of Typo3 - AFAIK there is know "Typo3 way" to delete the typo3temp/rtehtmlarea*.js - but this is important!

BTW: I also use FF Linux 2.0.0.3 and my extensions (1.4.3a and 1.5.1a-dev) are working for me.

Ok. I confirm that this works for me now, too. No clue why I could not get it to work before.

Just a question: Why is htmlarearte 1.5.1dev NOT in TER??

Probably this would be much easier to handle for most users. ;)

@Post 0013364 and all others which may be confused:
The only thing you have to get rid of is the Browserversion check 'is_wamcom' in connection with gecko browsers. This works I think for everyone in the described way ( -> patch both, htmlarea.js AND htmlarea_compressed.js -> delete all rtehtmlarea* files from typo3temp, -> clean your browsers cache and restart it!).
The way, how to get rid of the faulty wamcom test may be different ... (Depends on the needs of each installation -> Version of t3, version of htmlarea....)

I uploaded the new extension versions for TYPO3 3.7 and TYPO3 3.8. Please do not use them for TYPO3 4.x releases!!
End of this week there will be new patch-level releases of TYPO3 4.0 Core and TYPO3 4.1 Core which will include the fix on RTEhtmlarea. The RTEhtmlarea is since TYPO3 4.0 part of the Core and thus developed with the Core.

T3X_rtehtmlarea-1_1_6-z--TYPO3-3_7.t3x (RTEhtmlarea 1.1.6 for TYPO3 3.7 only)
T3X_rtehtmlarea-1_2_2-z--TYPO3-3_8.t3x (RTEhtmlarea 1.2.2 for TYPO3 3.8 only)

TYPO3 3.7 & 3.8 users: Please test these extensions and tell, if there are any problems on your releases. These extension upgrades will be published on the TER tomorrow.

Will there be a new version of TYPO3? - should be. It's not fair to patch a fresh install of TYPO3.

Morten, as mentioned one post before yours:
There will be new patch-level releases of TYPO3 4.0 and 4.1, which means:
TYPO3 4.0.6 and TYPO3 4.1.1 as new releases.

Fixed in SVN: Trunk, TYPO3-4_1, TYPO3-4_0

Okay, there were three new releases published to TER:

• 1.1.6 (replacing 1.1.5) for the TYPO3 3.7 branch
• 1.2.2 (replacing 1.2.1) for the TYPO3 3.8 branch
• 1.4.4 (replacing 1.4.3) for the TYPO3 4.0 branch (including the features by Stanislav that are not in Core)

Today or tomorrow there will be prerelease of 4.0.6 and 4.1.1. If nobody objects, the final patch-level releases will be published at the beginning of the next week. The versions that are part of the Core as system extensions were not uploaded to TER, these are:

• 1.3.9 (replacing 1.3.8) only in TYPO3 4.0.6! Not in TER!
• 1.5.2 (replacing 1.5.1) only in TYPO3 4.1.1! Not in TER!

Just check http://typo3.org/download/packages/ for new releases the next few days...

Several patches for different TYPO3 branches were published in TER and SVN. New releases of the 4.0.x and 4.1.x branches will be available in the next few days.

If you experience further problems concerning this issue and thus, only on Firefox 2.0.0.3, please make sure that you've installed the correct version of the extension, check if you're using a local extension or a system extension and finally clear the system cache. If the problem remains, please open a new bug-report and describe your problem in detail.

Thanks to anyone who supported TYPO3 to solve this bug by testing, researching, coding and whatever!

This bug is resolved and fixed!

Best regards,
Olly