Bug #20377

External Links get prepended with http://typo3 in the RTEhtmlarea in Firefox 3.0.11/3.5b4

Added by Markus Cousin over 7 years ago. Updated almost 5 years ago.

Status:Resolved Start date:2009-04-29
Priority:Should have Due date:
Assigned To:Oliver Hader % Done:

0%

Category:- Spent time: -
Target version:-
TYPO3 Version: Complexity:
PHP Version: Is Regression:
Tags: Sprint Focus:

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)

0011009_experimental.patch Magnifier (1.1 kB) Administrator Admin, 2009-06-14 02:28

0011009_v2.patch Magnifier (1.1 kB) Administrator Admin, 2009-06-16 13:26

0011009_v3.patch Magnifier (1014 Bytes) Administrator Admin, 2009-06-16 16:28

0011009_v3.4.1.10.patch Magnifier (17.5 kB) Administrator Admin, 2009-06-16 16:29

0011009.patch Magnifier (1014 Bytes) Administrator Admin, 2009-06-18 09:20

0011009_4-1.patch Magnifier (17.3 kB) Administrator Admin, 2009-06-18 09:20

rtehtmlarea_bugfix_11009_follow_up_trunk.patch Magnifier (2.1 kB) Administrator Admin, 2009-07-01 18:51

rtehtmlarea_bugfix_11009_follow_up_typo3_4-2.patch Magnifier (2.7 kB) Administrator Admin, 2009-07-01 20:14

rtehtmlarea_bugfix_11009_follow_up_typo3_4-1.patch Magnifier (1.3 kB) Administrator Admin, 2009-07-01 20:32


Related issues

related to Core - Bug #19232: Unable to create an external URL in the rtehtmlarea link ... Resolved 2008-08-19
duplicated by Core - Bug #20879: External URLs get prefixed with http://typo3/ Closed 2009-08-14
duplicated by Core - Bug #20620: Setting a mailto: - Link with RTE creates an unuseable Link Closed 2009-06-15
duplicated by Core - Bug #20824: External and internal lin11009ks get prepended with http:... Resolved 2009-08-03

History

#1 Updated by Jason Lefkowitz over 7 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.

#2 Updated by Alexander von Drach over 7 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...

#3 Updated by Markus Cousin over 7 years ago

Problem still exists with Firefox 3.5b99

#4 Updated by Niels Fröhling over 7 years ago

I can confirm this for FF 3.5ß5 and Typo3-SVN

#5 Updated by Carsten Pohle over 7 years ago

Confirm this bug for FF 3.0.11 for internal links

#6 Updated by Jasmin Woyder over 7 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.

#7 Updated by Administrator Admin over 7 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.

#8 Updated by Peter Linzenkirchner over 7 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.

#9 Updated by Marcus Krause over 7 years ago

Can confirm it with FF 3.0.11 and branch TYPO3_4.2 (rev 5340).

#10 Updated by Erik Svendsen over 7 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 7 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...

#12 Updated by Oliver Hader over 7 years ago

FYI: Just to make sure this gets somehow integrated in a upcoming 4.2 patch level release... ;)

#13 Updated by Erik Svendsen over 7 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.

#14 Updated by Philipp Gampe over 7 years ago

Firefox Update 3.0.11is out and Link creation is brocken...
Priority should be set to High

#15 Updated by Florian Schaeffer over 7 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.

#16 Updated by marvin over 7 years ago

Patch does not work for me either.

#17 Updated by Ralf Hettinger over 7 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 ...

#18 Updated by Martin Kuster over 7 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..

#19 Updated by Carsten Pohle over 7 years ago

Patch 0011009_experimental.patch does not work for me either

#20 Updated by Sonja Schubert over 7 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...

#21 Updated by Martin Kuster over 7 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

#22 Updated by Peter Kuehn over 7 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

#23 Updated by Sonja Schubert over 7 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

#24 Updated by Administrator Admin over 7 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...

#25 Updated by Maik Matthias over 7 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

#26 Updated by Jochen Rieger over 7 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):

http://www.mydomain.de/typo3/http://www.mydomain.de/?id=7

#27 Updated by Martin Kuster over 7 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 7 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>

#29 Updated by Oliver Hader over 7 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

#30 Updated by Administrator Admin over 7 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 :-)

#31 Updated by Roland Behme over 7 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

#32 Updated by Koen TILLEY over 7 years ago

It now also works for me ... "remove the cached files in typo3temp/rtehtmlarea/" was the part I was missing

#33 Updated by Administrator Admin over 7 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.

#34 Updated by Steffen Müller over 7 years ago

confirmed using FF 3.0.11 (Ubuntu 8.10 package) and TYPO 4.2.6
0011009_experimental.patch resolves the issue.

#35 Updated by Jigal van Hemert over 7 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???

#36 Updated by Erik Svendsen over 7 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 7 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

#38 Updated by Michael over 7 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 …

#39 Updated by Christian Zenker over 7 years ago

Removing encodeURIComponent() / decodeURIComponent() recreates bug #9196 . 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.

#40 Updated by Administrator Admin over 7 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.

#41 Updated by Christian Zenker over 7 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?

#42 Updated by Martin Kuster over 7 years ago

Attached 0011009_v2.patch with Christian's solution.

Works for me. (Fixes this bug and doesn't break #9196)

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

#43 Updated by Christian Zenker over 7 years ago

tested 0011009_v2.patch on FF 2.0.0.20 - works.

#44 Updated by Georg Ringer over 7 years ago

testet FF 3.011 working patches are
t3_4.2.6_patched_typo3link.js.diff & 0011009_v2.patch-

#45 Updated by Clemens Riccabona over 7 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.

#46 Updated by Administrator Admin over 7 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.

#47 Updated by David Zschille over 7 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.

#48 Updated by Martin Kuster over 7 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)

#49 Updated by David Zschille over 7 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.

#50 Updated by Administrator Admin over 7 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.

#51 Updated by Martin Kuster over 7 years ago

@Hanspeter Siegfried: Is your installation patched? Or does the attached patch solve the issue?

#52 Updated by Steffen Gebert over 7 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!

#53 Updated by Kay Strobach over 7 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. ;)

#54 Updated by Markus Volkmer over 7 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...

#55 Updated by Oliver Hader over 7 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 7 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

#57 Updated by Christian Zenker over 7 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.

#58 Updated by Karl Schlicker over 7 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?

#59 Updated by Oliver Hader over 7 years ago

Committed to SVN:
  • 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

#60 Updated by Stanislas Rolland about 7 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 about 5 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/

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).

#62 Updated by Jan Simbera about 5 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.

#63 Updated by Steffen Becker almost 5 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).

#64 Updated by Dominik Müller almost 5 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).

Also available in: Atom PDF