Project

General

Profile

Actions

Bug #20377

closed

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

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

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
2009-04-29
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
PHP Version:
Tags:
Complexity:
Is Regression:
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)


Files

0011009_experimental.patch (1.07 KB) 0011009_experimental.patch Administrator Admin, 2009-06-14 02:28
0011009_v2.patch (1.05 KB) 0011009_v2.patch Administrator Admin, 2009-06-16 13:26
0011009_v3.patch (1014 Bytes) 0011009_v3.patch Administrator Admin, 2009-06-16 16:28
0011009_v3.4.1.10.patch (17.5 KB) 0011009_v3.4.1.10.patch Administrator Admin, 2009-06-16 16:29
0011009.patch (1014 Bytes) 0011009.patch Administrator Admin, 2009-06-18 09:20
0011009_4-1.patch (17.3 KB) 0011009_4-1.patch Administrator Admin, 2009-06-18 09:20
rtehtmlarea_bugfix_11009_follow_up_trunk.patch (2.07 KB) rtehtmlarea_bugfix_11009_follow_up_trunk.patch Administrator Admin, 2009-07-01 18:51
rtehtmlarea_bugfix_11009_follow_up_typo3_4-2.patch (2.68 KB) rtehtmlarea_bugfix_11009_follow_up_typo3_4-2.patch Administrator Admin, 2009-07-01 20:14
rtehtmlarea_bugfix_11009_follow_up_typo3_4-1.patch (1.33 KB) rtehtmlarea_bugfix_11009_follow_up_typo3_4-1.patch Administrator Admin, 2009-07-01 20:32

Related issues 4 (0 open4 closed)

Related to TYPO3 Core - Bug #19232: Unable to create an external URL in the rtehtmlarea link wizzard containing german umlautsClosedStanislas Rolland2008-08-19

Actions
Has duplicate TYPO3 Core - Bug #20620: Setting a mailto: - Link with RTE creates an unuseable LinkClosed2009-06-15

Actions
Has duplicate TYPO3 Core - Bug #20879: External URLs get prefixed with http://typo3/ClosedStanislas Rolland2009-08-14

Actions
Has duplicate TYPO3 Core - Bug #20824: External and internal lin11009ks get prepended with http://yourdomain.org/typo3 in Firefox 3.5.1 / typo3 4.2.6ClosedChristian Kuhn2009-08-03

Actions
Actions #1

Updated by Jason Lefkowitz almost 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.

Actions #2

Updated by Alexander von Drach almost 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...

Actions #3

Updated by Markus Cousin almost 15 years ago

Problem still exists with Firefox 3.5b99

Actions #4

Updated by Niels Fröhling almost 15 years ago

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

Actions #5

Updated by Carsten Pohle almost 15 years ago

Confirm this bug for FF 3.0.11 for internal links

Actions #6

Updated by Jasmin Woyder almost 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.

Actions #7

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

Actions #8

Updated by Peter Linzenkirchner almost 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.

Actions #9

Updated by Marcus Krause almost 15 years ago

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

Actions #10

Updated by Erik Svendsen almost 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.

Actions #11

Updated by Oliver Hader almost 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...

Actions #12

Updated by Oliver Hader almost 15 years ago

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

Actions #13

Updated by Erik Svendsen almost 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.

Actions #14

Updated by Philipp Gampe almost 15 years ago

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

Actions #15

Updated by Florian Schaeffer almost 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.

Actions #16

Updated by marvin almost 15 years ago

Patch does not work for me either.

Actions #17

Updated by Ralf Hettinger almost 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 ...

Actions #18

Updated by Martin Kuster almost 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..

Actions #19

Updated by Carsten Pohle almost 15 years ago

Patch 0011009_experimental.patch does not work for me either

Actions #20

Updated by Sonja Schubert almost 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...

Actions #21

Updated by Martin Kuster almost 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

Actions #22

Updated by Peter Kuehn almost 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

Actions #23

Updated by Sonja Schubert almost 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

Actions #24

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

Actions #25

Updated by Maik Matthias almost 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

Actions #26

Updated by Jochen Rieger almost 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):

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

Actions #27

Updated by Martin Kuster almost 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?)

Actions #28

Updated by Markus Wanjura almost 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>

Actions #29

Updated by Oliver Hader almost 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

Actions #30

Updated by Administrator Admin almost 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 :-)

Actions #31

Updated by Roland Behme almost 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

Actions #32

Updated by Koen TILLEY almost 15 years ago

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

Actions #33

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

Actions #34

Updated by Steffen Müller almost 15 years ago

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

Actions #35

Updated by Jigal van Hemert almost 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???

Actions #36

Updated by Erik Svendsen almost 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.

Actions #37

Updated by Erik Svendsen almost 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

Actions #38

Updated by Michael almost 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 …

Actions #39

Updated by Christian Zenker almost 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.

Actions #40

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

Actions #41

Updated by Christian Zenker almost 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?

Actions #42

Updated by Martin Kuster almost 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

Actions #43

Updated by Christian Zenker almost 15 years ago

tested 0011009_v2.patch on FF 2.0.0.20 - works.

Actions #44

Updated by Georg Ringer almost 15 years ago

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

Actions #45

Updated by Clemens Riccabona almost 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.

Actions #46

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

Actions #47

Updated by David Zschille almost 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.

Actions #48

Updated by Martin Kuster almost 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)

Actions #49

Updated by David Zschille almost 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.

Actions #50

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

Actions #51

Updated by Martin Kuster almost 15 years ago

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

Actions #52

Updated by Steffen Gebert almost 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!

Actions #53

Updated by Kay Strobach almost 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. ;)

Actions #54

Updated by Markus Volkmer almost 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...

Actions #55

Updated by Oliver Hader almost 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

Actions #56

Updated by Administrator Admin almost 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

Actions #57

Updated by Christian Zenker almost 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.

Actions #58

Updated by Karl Schlicker almost 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?

Actions #59

Updated by Oliver Hader almost 15 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
Actions #60

Updated by Stanislas Rolland over 14 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

Actions #61

Updated by Chris over 12 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:

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

Actions #62

Updated by Jan Simbera over 12 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.

Actions #63

Updated by Steffen Becker over 12 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).

Actions #64

Updated by Dominik Müller over 12 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).

Actions #65

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF