Bug #20377
closedExternal Links get prepended with http://typo3 in the RTEhtmlarea in Firefox 3.0.11/3.5b4
0%
Description
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:
http://forge.typo3.org/repositories/diff/typo3v4-core?rev=4018
(issue imported from #M11009)
Files
Updated by Jason Lefkowitz over 15 years ago
I've been seeing this issue as well in 4.2.6 ever since I upgraded to Firefox 3.5 beta. Does not occur when I use Internet Explorer 8.
Updated by Alexander von Drach about 15 years ago
I've seen this with a pre-release of Firefox 3.0.11 as well (also with mail links, which are prefixed with 'typo3/'). Typo version was 4.2.6.
Maybe this problem will become urgent soon, the final release of 3.0.11 is scheduled for 4th of June...
Updated by Markus Cousin about 15 years ago
Problem still exists with Firefox 3.5b99
Updated by Niels Fröhling about 15 years ago
I can confirm this for FF 3.5ß5 and Typo3-SVN
Updated by Carsten Pohle about 15 years ago
Confirm this bug for FF 3.0.11 for internal links
Updated by Jasmin Woyder about 15 years ago
Not 100% the same issue but I can't create internals links anymore with FireFox 3.0.11 and typo3 4.2.6. It seems that the base_url part is appended twice.
Updated by Administrator Admin about 15 years ago
Same here. FF 3.0.11 (XP 32) and TYPO3 4.2.6.
Internal links added with htmlarea look like this:
http://$URL_of_backend/typo3/http://$URL_of_backend/?id=$Page_ID
IE 6 is fine.
Updated by Peter Linzenkirchner about 15 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.
Updated by Marcus Krause about 15 years ago
Can confirm it with FF 3.0.11 and branch TYPO3_4.2 (rev 5340).
Updated by Erik Svendsen about 15 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.
Updated by Oliver Hader about 15 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...
Updated by Oliver Hader about 15 years ago
FYI: Just to make sure this gets somehow integrated in a upcoming 4.2 patch level release... ;)
Updated by Erik Svendsen about 15 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.
Updated by Philipp Gampe about 15 years ago
Firefox Update 3.0.11is out and Link creation is brocken...
Priority should be set to High
Updated by Florian Schaeffer about 15 years ago
confirmed, although manual removal of the generated typo3-part of the URL helps, for now I have to use IE7 which is perfectly working :(
Please set priority to high as all users are getting the new FF version right now.
Updated by Ralf Hettinger about 15 years ago
0011009_experimental.patch works for me (Firefox 3.0.11 + rtehtmlarea 1.7.9).
Though I wonder, if there was/is a reason for passing theLink through encodeURIComponent in case of browser is_gecko ...
Updated by Martin Kuster about 15 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:1.9.0.10pre) Gecko/2009042306 GranParadiso/3.0.10pre ID:2009042306
First build with problem:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10pre) 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..
Updated by Carsten Pohle about 15 years ago
Patch 0011009_experimental.patch does not work for me either
Updated by Sonja Schubert about 15 years ago
Does somebody know where the php part is which the typo3/sysext/rtehtmlarea/htmlarea/plugins/TYPO3Link/typo3link.js includes? I would like to create a clean xclass extension which solves this problem...
Updated by Martin Kuster about 15 years ago
0011009_experimental.patch solves the issue here (4.2.6). (after clearing all caches and restarting firefox)
Successfully tested against various older and latest trunk builds of FF 3.0.X
Updated by Peter Kuehn about 15 years ago
Hi yall, Hi Sonja,
Does somebody know where the php part is which the
typo3/sysext/rtehtmlarea/htmlarea/plugins/TYPO3Link/typo3link.js
includes?
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
gRTz
pekue
Updated by Sonja Schubert about 15 years ago
Hi Peter,
thank you for your fast answer.
Now I created an xclass of that function in class.tx_rtehtmlarea_base.php to use my own version of typo3link.js. This xclass works.
Kind regards,
Sonja
Updated by Administrator Admin about 15 years ago
0011009_experimental.patch solves the issue here (4.2.6). (after clearing all caches and restarting firefox)
0011009_experimental.patch works for me too.
TYPO3 4.2.6, FF 3.0.11, RTE 1.7.9
But I wonder if this is a Typo3-Bug now or a Firefox one...
Updated by Maik Matthias about 15 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...
Maik
Updated by Jochen Rieger about 15 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):
Updated by Martin Kuster about 15 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?)
Updated by Markus Wanjura about 15 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.
<script type="text/javascript"> foo = encodeURIComponent("http://www.example.com"); document.write(encodeURIComponent("http://www.example.com")); document.write(decodeURIComponent(foo)); </script>
Updated by Oliver Hader about 15 years ago
Hi all,
if you test the patch (or any other RTEhtmlare patch), please make sure to remove the cached files in typo3temp/rtehtmlarea/
Cheers, Olly
Updated by Administrator Admin about 15 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 :-)
Updated by Roland Behme about 15 years ago
The patch worked for me too. On 4.1.10 the JS files of the RTE are somewhat different, I created a patch for 4.1.10 based on the one from Oliver for 4.2.6.
Please see 0011009_experimental.4.1.10.patch
Updated by Koen TILLEY about 15 years ago
It now also works for me ... "remove the cached files in typo3temp/rtehtmlarea/" was the part I was missing
Updated by Administrator Admin about 15 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.
Updated by Steffen Müller about 15 years ago
confirmed using FF 3.0.11 (Ubuntu 8.10 package) and TYPO 4.2.6
0011009_experimental.patch resolves the issue.
Updated by Jigal van Hemert about 15 years ago
Also tested in FF 3.0.11 on Windows XP and TYPO3 4.2.6
It took quite a bit of effort getting all cached items out of the way, but it works!
Can we please get this issue fixed in the next releases???
Updated by Erik Svendsen about 15 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.
Updated by Erik Svendsen about 15 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
Updated by Michael about 15 years ago
This issue is also effecting E-Mail Links via RTE.
The 4.2.6 patch works for both type of links: External and E-Mail.
Thanks.
I just included a Diff-File for those who want to see the changes …
Updated by Christian Zenker about 15 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.
Updated by Administrator Admin about 15 years ago
Using decodeURI()/encodeURI() instead of the ~Component version should solve this problem once and for all.
Did you successfully test your solution?
I use T3 4.2.6 and for me it doesn't work.
Updated by Christian Zenker about 15 years ago
Did you successfully test your solution?
I use 4.2.6 myself and tried FF 3.0.11 on Ubuntu and Win Vista - successfully. Are you sure, you cleared all caches?
Updated by Martin Kuster about 15 years ago
Attached 0011009_v2.patch with Christian's solution.
Works for me. (Fixes this bug and doesn't break #0009196)
btw. tested with:
- latest FF 3.0.x trunk
- FF 3.0.11
- FF 3.0.10 (before the FF fix)
- latest FF 3.5pre trunk
Updated by Christian Zenker about 15 years ago
tested 0011009_v2.patch on FF 2.0.0.20 - works.
Updated by Georg Ringer about 15 years ago
testet FF 3.011 working patches are
t3_4.2.6_patched_typo3link.js.diff & 0011009_v2.patch-
Updated by Clemens Riccabona about 15 years ago
I can confirm bug with FF 3.0.11 (Win XP SP3) and the latest solution (0011009_v2.patch) but without testing IDN-Domains.
Updated by Administrator Admin about 15 years ago
Patch v2 works for me too now.
I forgot to set "forceCharset" to utf-8 ;-)
Everything works fine with FF 3.0.11 and T3 4.2.6.
Updated by David Zschille about 15 years ago
Doesn't work for me.
Testet with
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.
Updated by Martin Kuster about 15 years ago
Added a clean version v3 (removed the commented line) for 4.2.6/trunk and a version for 4.1.10.
Patch for 4.1.10 worked after manually removing all files from typo3temp/ (install-tool didn't remove them) and clearing all browser caches (new FF-profile)
Updated by David Zschille about 15 years ago
now after manually removing all files from typo3temp/ (install-tool didn't remove them) the Patch works for me.
Tested with 0011009_v2.patch and FF 3.0.11 running on Ubuntu.
Updated by Administrator Admin about 15 years ago
External links work in our installation, but when a non-admin redactor places media links, it doesn't work. RTE produces those "http://typo3/https://www.kzo.ch/fileadmin/..."-links.
Updated by Martin Kuster about 15 years ago
@Hanspeter Siegfried: Is your installation patched? Or does the attached patch solve the issue?
Updated by Steffen Gebert about 15 years ago
So is this ready to be sent to the core list?
What do you plan, Olly?
IMHO releasing a bug-fix release is very urgent!
Updated by Kay Strobach about 15 years ago
internal link problem is still present in ff 3.0.11 and typo3 4.2.6 -> would be nice, if this could be fixed in the next release, it's confusing some people. ;)
Updated by Markus Volkmer about 15 years ago
still present in FF 3.0.11 and TYPO3 4.2.6 after 0011009_v3.patch and clearing whole cache and clearing ./typo3temp/rtehtmlarea/*
edit: now patch works here too (tested with T3-4.2.6 & T3-4.3.0_alpha3) - missed to really clear browser-cache...
Updated by Oliver Hader about 15 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
Updated by Administrator Admin about 15 years ago
Patch 0011009_v2.patch works on T3 4.2.6, rtehtmlarea 1.7.9
Apply patch on linux with:
ls -la
:
typo3/
:
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
Updated by Christian Zenker about 15 years ago
I included the patch and tried the following versions of Firefox on Ubuntu 8.10:
- 3.5rc1
- 3.0.11 (of course)
- 3.0 (first release)
- 2.0.0.20
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.
I used T3 4.2.6, but as this is soley an JavaScript fix, other versions should work, too.
Updated by Karl Schlicker about 15 years ago
The bugfix will be in TYPO3 4.1.11, 4.2.7 and 4.3-beta1
Did you now the release date of the TYPO3 versions? Probally this month?
Updated by Oliver Hader about 15 years ago
- TYPO3_4-1 (rev. 5597) --> TYPO3 4.1.11
- TYPO3_4-2 (rev. 5598) --> TYPO4 4.2.7
- Trunk (rev. 5599) --> TYPO3 4.3-beta1
Updated by Stanislas Rolland about 15 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
Updated by Chris almost 13 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:typo3/email@address.com
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).
Updated by Jan Simbera almost 13 years ago
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.
Updated by Steffen Becker almost 13 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).
Updated by Dominik Müller almost 13 years ago
Same at my site, using FF 7.0.1 and Typo3 4.5.6 on Windows 7, mailto-links are broken. SSL on backend is enabled. Chrome is fine as Jan said.
Update: Everything seems to be fine after disabling SSL for backend (only active for login at the moment).
Updated by Benni Mack almost 6 years ago
- Status changed from Resolved to Closed