Bug #17269
closed
Links with RTE HTMLarea 1.2.2 on Typo3 3.8.x are broken - again!!!
0%
Description
I had to fix it with 1.2.1 of RTE HTMLarea after the security patch release, submitted all required sources and information. It was also reviewed - haven't heared something since that time - but is was not rejected whatsoever. Has not been published on the security bulletin which still suggests to use the broken version. Anyhow - now a patch due to the Firefox 2.0.0.3 issue. And of course the patch has been done as well on the wrong, broken source of 1.2.1 instead of a fixed one. In the result the version is broken as well and in the same way as the 1.2.1.
The link tool inside RTE HTMLarea 1.2.2 are broken, so you can not set any links.
The patch is easy and is attached here.
Patch team: Please update this also on TER otherwise stop supporting 3.8!
(issue imported from #M5541)
Files
Updated by Michael Stucki almost 17 years ago
This is not a patch, it's a new build. Please create a patch and help to make me find the changes you have made.
See http://typo3.org/development/bug-fixing/diff-and-patch/ on how to do that.
- michael
Updated by Olaf Bottek almost 17 years ago
Michael: diff and txt was inside the package - the interface allowed only one file with the submit. Anyhow - I have added it now. Description is:
In:
/<your-site>/typo3/ext/rtehtmlarea/mod3/browse_links.php
Replace:
setClass(document.ltargetform.anchor_class.value);
by:
if (document.ltargetform.anchor_class) setClass(document.ltargetform.anchor_class.value);
in lines:
901, 908, 914, 920
This solves links to pages, files, external urls and email addresses.
Updated by Maria almost 17 years ago
I have implemented this solutions, but it don't work correctly in Firefox.
Please i nedd a solution.
Thank you.
Updated by Michael Stucki almost 17 years ago
@Olaf: please have a look at my link in note #13887 about how patches must look like. Having no context and filename specified makes it pretty hard to guess...
Additionally, it seems that the file you mentioned (browse_links.php) is not the right one, at least not in current Trunk. So probably you were right with your fix for version 1.2.2, but then we also need to check first if the bug is still reproducable in Trunk. Can one of you do that, please?
After all I didn't try to reproduce the bug yet, but according to the logics, it seems that there's just one missing check that needs to be added. I have changed that in the attached patch - please check.
Updated by Olaf Bottek almost 17 years ago
@Maria: Well I have tested this with Firefox and it works (Windows versions and platforms). Also a large amount of users with IE and Firefox is using it on a daily basis.
@Michael: I'm not really sure for which version your bug.diff should work. At least for 1.2.2 you are fixing only one of four positions were the same bug is happing. Therefor it will still be broken in this version. I just also fetched the vanilla 1.2.2 again and looked in to the source - my patch is correcting the right lines and is working.
I can not say something about the "current" - whatever you call current. This bug report/patch was about 1.2.2 for Typo3 3.8.x. Newer Typo3 version use newer RTEHTMLAREA versions and they don't seam to have the problem.
Updated by Stanislas Rolland almost 16 years ago
Fixed in version 1.2.4.
Indeed support for TYPO3 3.8 was dropped a while ago. Consider upgrading to most recent TYPO3 release as soon as possible.
Updated by