TYPO3 Core

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.

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

Problem still exists with Firefox 3.5b99

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

Confirm this bug for FF 3.0.11 for internal links

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.

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.

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.

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

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.

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

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

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.

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

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.

Patch does not work for me either.

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

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

Patch 0011009_experimental.patch does not work for me either

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

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

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

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

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

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

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

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

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>

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

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

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

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

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.

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

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???

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.

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

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 …

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.

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.

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?

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

tested 0011009_v2.patch on FF 2.0.0.20 - works.

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

I can confirm bug with FF 3.0.11 (Win XP SP3) and the latest solution (0011009_v2.patch) but without testing IDN-Domains.

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.

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.

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)

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.

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.

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

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!

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

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

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

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

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.

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?

• 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

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

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

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.

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

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