External Links get prepended with http://typo3 in the RTEhtmlarea in Firefox 3.0.11/3.5b4
Setting external Links will cause into a prefixed external Link with http://typo3 at the beginning.
Tested in TYPO3 4.2.5 & TYPO3 4.2.6
The special handling for Gecko browsers was introduced in rev. 4018:
(issue imported from #M11009)
#7 Updated by Administrator Admin over 10 years ago
Same here. FF 3.0.11 (XP 32) and TYPO3 4.2.6.
Internal links added with htmlarea look like this:
IE 6 is fine.
#8 Updated by Peter Linzenkirchner over 10 years ago
The problem exists in Typo3 4.3 in both alfa releases with the actuell version of Firefox (3.0.11). Internal links are broken too. The problem is urgent because firefox automatic update installes this version these days.
Safari 4.0 / Mac works fine.
#10 Updated by Erik Svendsen over 10 years ago
Can also confirm.
Debug of $this->curUrlArray in class.tx_rtehtmlarea_browse_links.php gives, http://$URL_of_site/typo3/http://$URL_of_site/?id=$Page_ID when debugging in Firefox. (making kink)
Debugging in Safari gives correct values.
There are also wrong values in $this->curUrlInfo
Not sure if this helps, and I haven't had time to look further into the logic and problem.
#11 Updated by Oliver Hader over 10 years ago
I tracked down the problem to the file typo3/sysext/rtehtmlarea/htmlarea/plugins/TYPO3Link/typo3link.js and the URI handling there for Gecko browsers (encodeURIComponent/decodeURIComponent).
I think the real problem can be found in "execCommand("CreateLink", ...) - however I was not able to find the correct place where the "execCommand" call for "CreateLink" gets really handled.
Attached an experimental fix...
#13 Updated by Erik Svendsen over 10 years ago
The experimental fix did not solve the problem in my case: Tested on following:
Firefox 3.0.11, TYPO3 4.2.6 and TYPO3 4.3.0alpha3.
I'm not sure the problem is in typo3link.js at all.
About the "CreateLink", it looks like it calls the button for Create Link in the RTE.
#18 Updated by Martin Kuster over 10 years ago
I did some checks with older firefox nightly builds (3.0.x/1.9.0.x).
Latest build without this problem:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/2009042306 GranParadiso/3.0.10pre ID:2009042306
First build with problem:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199pre) Gecko/2009042405 GranParadiso/3.0.10pre ID:2009042405
Looks like https://bugzilla.mozilla.org/show_bug.cgi?id=481647 introduced this problem. (One of the JS fixes for 3.0.11, committed on 23.04.06)
Hope that helps finding a fix..
#22 Updated by Peter Kuehn over 10 years ago
Hi yall, Hi Sonja,
Does somebody know where the php part is which the
take a look at typo3/sysext/rtehtmlarea/class.tx_rtehtmlarea_base.php
Line 781 adds entries to HTMLArea_plugins, an array that contains the plugins to be loaded and TYPO3link is one of them. (the file is compressed on beforehand)
typo3/sysext/rtehtmlarea/htmlarea/htmlarea.js Line 209 traverses the Array and _getScript() (Line 109) finally loads the files via AJAX.
hope that helps
#25 Updated by Maik Matthias over 10 years ago
Can confirm the problem with FF 3.0.11 shipped via autoupdate today. Manual removal of the wrong part in generated URL does not work. I think priority level should be set to high, cause it´s impossible now to use FF with typo3.
> But I wonder if this is a Typo3-Bug now or a Firefox one...
I wonder too...
#26 Updated by Jochen Rieger over 10 years ago
Confirming the problem using FF 3.0.11 and TYPO3 4.1.10 as well.
The URLs created are somehow doubled (well, prefixed with the backend url):
#27 Updated by Martin Kuster over 10 years ago
But I wonder if this is a Typo3-Bug now or a Firefox one...
I think it's a TYPO3 bug - because the patched version also works with older FF 3.0.X versions..
(OK, the current version also worked because of a bug in FF [imho]. But should we ask them to revert that?)
#28 Updated by Markus Wanjura over 10 years ago
Doesn't matter what i do, the patch wont work for me.
If i check the js functions from the patch in a normal html document in all browsers, everything works fine.
#30 Updated by Administrator Admin over 10 years ago
I wonder whether everybody understands the patch.
Actually, the encoding and decoding of the url is commented out for gecko engines.
I uploaded my patched js-file that worked fine for me.
You can download it at the top of this page.
Please look at lines 165 and 249 to see the changes I made.
Hope that helps :-)
#33 Updated by Administrator Admin over 10 years ago
As I saw the relation to bug 0009196 I tested the patches of the js-file by linking to an url that contains a german umlaut like ä or ß and of course it makes problems as well because the patch to this bug is removing the patch of bug 0009196.
So, external links and mailto links crash by using an umlaut.
Links to files like "somethingä.txt" work and of course links to pages that contain umlauts work as well due to realurl e.g. doesn't know umlauts.
In the end there has to be written a new patch, however this must lool like.
#36 Updated by Erik Svendsen over 10 years ago
In some instances you have to clear cookies and all browser cache to. Even after deleting typo3temp/rtehtmlarea/-files more than once, restarting the browser, reloading page with Ctrl-F5, same problems.
Deleting all browser cache and cookies solved the problem at the end. And the patch works.
#37 Updated by Erik Svendsen over 10 years ago
A short notice on version 4.1.10,regarding Rolands patch
4.1.10 has to different js-files, one is compressed. If you only change the uncompressed, you also have to change settings for HTMLArea in EM.
Cache files are in typo3temp, not in typo3tem/rtehtmlarea.
Else the 4.1.10 patch works as far as I can see. Uploaded a patched version of compressed js-file
#39 Updated by Christian Zenker over 10 years ago
Removing encodeURIComponent() / decodeURIComponent() recreates bug #0009196 . It is not possible to use special characters in the links. Using decodeURI()/encodeURI() instead of the ~Component version should solve this problem once and for all. (Im not familiar with svn - could anyone please submit a diff?)
To understand the issue:
According to the research of Martin Kuster, the error first appeared in Firefox when every document was forced to have a baseURL (https://bugzilla.mozilla.org/attachment.cgi?id=370479&action=diff , nsDocShell::CreateAboutBlankContentViewe, line 5436). encodeURIComponent() encodes (edit: almost) every non-alphanum char, i.e. including / and : . Firefox doesn't recognize this as a qualified uri and adds the base uri. I guess that prior to the firefox patch the baseURL was empty and so it didn't change anything.
#47 Updated by David Zschille over 10 years ago
Doesn't work for me.
t3_4.2.6_patched_typo3link.js.diff and 0011009_v2.patch
on FF 3.0.11 running on Ubuntu, WinXP and Mac OS X.
T3 is 4.2.6. I don't know if it matters, but "forceCharset" is set to utf-8.
The T3 installation runs two websites.
#55 Updated by Oliver Hader over 10 years ago
The patches for TYPO3 4.1 and TYPO3 4.2/4.3 have been posted on the Core List.
Please test the patches - and especially make sure that everything still works with Firefox 2 and Firefox <3.0.11. Thanks!
The bugfix will be in TYPO3 4.1.11, 4.2.7 and 4.3-beta1
#56 Updated by Administrator Admin over 10 years ago
Patch 0011009_v2.patch works on T3 4.2.6, rtehtmlarea 1.7.9
Apply patch on linux with:
cp -a typo3/sysext/rtehtmlarea/htmlarea/plugins/TYPO3Link/typo3link.js typo3/sysext/rtehtmlarea/htmlarea/plugins/TYPO3Link/typo3link.js.ori
patch -p0 < 0011009_v2.patch
Afterwards, be sure to clean caches in this order:
rm -f typo3temp/rtehtmlarea/*
Typo3 BE : Clear all caches
Firefox: Extras|Settings| Erase private data
#57 Updated by Christian Zenker over 10 years ago
I included the patch and tried the following versions of Firefox on Ubuntu 8.10:
- 3.0.11 (of course)
- 3.0 (first release)
I created an external link using umlauts and [ ], and linked to an internal link on each version. I didn't encounter any problem.
Even the earlier versions of FF (1.5 and 1.0) seem to work with the patch.
#60 Updated by Stanislas Rolland about 10 years ago
The problem persists when no scheme is specified on the link. Firefox prepends the current base URL to the href attribute.
The attached follow up patch will prepend httt:// to the href attribute when no scheme is specified
Committed to SVN:
- trunk (revision 5667) --> TYPO3 4.3 beta1
- TYPO3_4-2 (revision 5668) --> TYPO3 4.2.7
- TYPO3_4-1 (revision 5669) --> TYPO3 4.1.11
#61 Updated by Chris almost 8 years ago
After an upgrade to 4.5.5 from 4.0 I'm getting the same issue - using the RTE it prepends extra mailto:typo3/ to an email address. Worse, each time you save it it prepends additional mailto:typo3/, so you end up with mailto:typo3/mailto:typo3/mailto:firstname.lastname@example.org
I've cleared RTEHtmlArea, cleared caches on browser and Typo3 to no avail. Error occurs in FF 3.6, and FF6 and Safari (probably more, but I haven't tested further).
#63 Updated by Steffen Becker almost 8 years ago
Jan Simbera wrote:
I have detected the same issue on version 4.5.6 in FF6.
Prepends mailto:/typo3 repeatedly, when u add and e-mail link in RTE.
Same here, using FF 7.0.1 and Typo3 4.5.6 on Snow Leopard 10.6.8 -- mailto-links are broken and so
are links created by linkhandler extension. Having absolutely no problems on Chrome (latest stable).