htmlarea doesn't load with new Firefox 22.214.171.124
with v1.5dev (shipped with typo3 4.1)
going back to FF 126.96.36.199 works well
(issue imported from #M5266)
#4 Updated by Christian Hernmarck over 10 years ago
It appeared with FF 188.8.131.52 - but it still may be a bug in HTMLArea...
#5 Updated by Alexander Grein over 10 years ago
I have the same Problem on MAC and PC.
After updating from 184.108.40.206 to 220.127.116.11 the HTMLArea do not work anymore.
"editor has no properties"
In the generated rtehtmlarea_.....js file i found this definition:
Maybe this help's someone.
#7 Updated by Axel Klarmann over 10 years ago
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:18.104.22.168) Gecko/20070309 Firefox/22.214.171.124
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:126.96.36.199) Gecko/20070309 Firefox/188.8.131.52
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
#8 Updated by Stefan Precht over 10 years ago
I'm working on a TYPO3 4.0.4 installation with an htmlarea V1.4.3 using FireFox 184.108.40.206 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 load the editor a second time it hang up while loading.
Due to this there occured an other JS error.
"editor has no properties"
Function: HTMLArea.generatePlugins = function(editorNumber)
Line 1066: var editor = RTEarea[editorNumber]["editor"];
#9 Updated by Patrick Broens over 10 years ago
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 220.127.116.11. This is now checked if version number has not indexOf(".1.3").
See the patch
Thanks to Axel Klarmann for pointing in the right direction.
When testing delete all rtehtmlarea related files in typo3temp directory.
#12 Updated by Axel Jindra over 10 years ago
I have patched both js files without an error and the editor still won't load in FF 18.104.22.168 on Mac OS X
edit: I just tested the patch with FF 22.214.171.124 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.
#15 Updated by Patrick Broens over 10 years ago
In addition to bugreport 5279:
the patch for issue 5266 is incomplete.
the patch tries to exclude following browser identifier
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:126.96.36.199) Gecko/20070309 Firefox/188.8.131.52
with this line
HTMLArea.is_wamcom = (HTMLArea.agt.indexOf("wamcom") != -1) || (HTMLArea.is_gecko && HTMLArea.agt.indexOf("1.3") != -1 && HTMLArea.agt.indexOf(".1.3") == -1);
this condition will still won't exclude future firefox versions, example:
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:184.108.40.206) Gecko/20070309 Firefox/220.127.116.11
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 18.104.22.168
#16 Updated by Oliver Hader over 10 years ago
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.
#17 Updated by alexander onea over 10 years ago
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:
var str = "Mozilla/5.0 [...]; rv:1.3.0) Gecko[...]Firefox/22.214.171.124".toLowerCase();
var condition = str.indexOf("1.3") != -1 && str.indexOf(".1.3") -1;
... 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.
#18 Updated by Patrick Broens over 10 years ago
in reply to note 13266:
The string "Mozilla/5.0 [...]; rv:1.3.0) Gecko[...]Firefox/126.96.36.199" 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 188.8.131.52. 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.
#25 Updated by Jason Lefkowitz over 10 years ago
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.
#26 Updated by Marc Véron over 10 years ago
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.
#27 Updated by Christian Hernmarck over 10 years ago
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!!!
#28 Updated by Christian Hernmarck over 10 years ago
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.... :-)
#29 Updated by Christian Hernmarck over 10 years ago
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...
#30 Updated by Christoph Blömer over 10 years ago
The patch: T3X_rtehtmlarea-1_4_3a-z-200703251756.t3x
is working at my typo3 installation.
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.
#34 Updated by Michael Stucki over 10 years ago
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.
#36 Updated by Lars-Erik Forsberg over 10 years ago
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
#38 Updated by Robert Destigter over 10 years ago
I tried both .t3x files on a Firefox 184.108.40.206 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).
#40 Updated by Clemens Riccabona over 10 years ago
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.
#42 Updated by Clemens Riccabona over 10 years ago
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????
#43 Updated by Axel Klarmann over 10 years ago
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
#44 Updated by Christian Hernmarck over 10 years ago
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-',
#48 Updated by Christian Lerrahn over 10 years ago
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 220.127.116.11).
#49 Updated by Christian Hernmarck over 10 years ago
You're almost right. The problem is "solved" (FF 18.104.22.168 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 22.214.171.124 and my extensions (1.4.3a and 1.5.1a-dev) are working for me.
#51 Updated by Clemens Riccabona over 10 years ago
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....)
#52 Updated by Oliver Hader over 10 years ago
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.
#56 Updated by Oliver Hader over 10 years ago
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...
#57 Updated by Oliver Hader over 10 years ago
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 126.96.36.199, 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!