Closed Bug 613517 Opened 14 years ago Closed 13 years ago

URL is not maintained for links or images after copy/paste in contenteditable


(Core :: DOM: Editor, defect)

1.9.2 Branch
Windows XP
Not set





(Reporter: u218732, Assigned: ehsan.akhgari)



(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E)

Firefox incorrectly transforms urls for pasted links and images when copying and pasting within the same document that is hosted on a server, e.g. using a rich text editor such as CKEditor to edit the document. This occurs for urls that contain the hostname of the server or that are relative.

E.g. if the editor is hosted on, the following links:
<a href="">Link1</a>
<a href="/test.html">Link1</a>

when copied and pasted, become:
<a href="../test.html">Link1</a>
<a href="../../test.html">Link1</a>

Reproducible: Always

Steps to Reproduce:
In Firefox 3.6.11+
1. Create a html file under /foo/bar/car e.g. accessible at
2. Add a contenteditable div with some absolute and relative links and images e.g. 
<div contenteditable="true" id="contentArea">
	<a href="">Link1</a>
	<img src="">
	<a href="/test.html">test.html</a>
	<a href="/foo/test.html">/foo/test.html</a>

3. View the file in Firefox
4. Click in the editable area
5. Copy the links and paste within the contenteditable div
6. In firebug inspect the page, you will see the pasted links urls have been modified.
Actual Results:  
After copy/paste
Note the level I'm at:
http://<server-name>/foo/bar/car/copypaste.html, this affects how many "../" you see.
<div contenteditable="true" id="contentArea">
	<a href="../test.html">Link1</a>
	<img src="../test.jpg">
	<a href="../../../test.html">test.html</a>
	<a href="../../test.html">/foo/test.html</a>

Expected Results:  
After paste, href/src urls should be the same as the original content
<div contenteditable="true" id="contentArea">
	<a href="">Link1</a>
	<img src="">
	<a href="/test.html">test.html</a>
	<a href="/foo/test.html">/foo/test.html</a>

Behavior is similar in Firefox 3.5.15.

In Firefox 3.6.10 the issue wasn't as severe, relative links were converted to absolute urls, however this still isn't correct. Copy/pasted links should maintain the same url.
I believe the following bug may have introduced the more severe issues:

This is related to editing in a rich text area, e.g CKEditor -
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → 1.9.2 Branch
I'm not sure that I understand comment 0 correctly.  Are you saying that the pasted URLs are pointing to the incorrect pages/images?  Given your document URI <>, they look correct to me.

Also, are you using the <base> tag in your page?

Sorry, I got a bit confused myself trying to explain the issue :)

I'm not using the <base> tag, actually here is the full html:
		<title>Copy / Paste in Firefox</title>
		<div contentEditable="true">
			<a href="http://myServer/foo/bar/test.html">Link1</a>
			<br />
			<br />
			<img src="http://myServer/foo/bar/test.jpg"/>
			<br />
			<br />
			<a href="/test.html">test.html</a>
			<br />
			<br />
			<a href="/foo/test.html">/foo/test.html</a>

So I placed that html file (copypaste.html) under /foo/bar/car/ on my webserver (used Apache Server 2).
View the file in Firefox, i.e. browse to http://myServer/foo/bar/car/copypaste.html, click in the contenteditable div, copy and paste each link and view the pasted links in Firebug
Again, I don't see what the problem is, exactly.  Is the resolved target of the links after the paste operation incorrect?
Hey Ehsan,

Yes the resolved target of the links after the paste operation are incorrect. I've attached 2 screenshots of the example I used, notice in the second screenshot (after the copy/paste) the resolved target of the links is not the same as the original link, e.g for the first 2 links which are absolute, the hostname has been stripped out.

I've also been able to reproduce this on the CKEditor nightly demo site:
This is a better demo page to use than as it contains more levels, i.e. /6110/_samples/ajax.html

Steps to reproduce.
1. In CKEditor, delete all content in the editor (just to tidy up the example)
2. Click the Source button (top left in editor)
3. In Source mode, paste in the following URL:
<a href="">Link</a>, 
It is important when entering an absolute URL for this example that the hostname matches the hostname in the URL bar, i.e. ""
4. Return to the Rick Text mode by clicking on the Source button again
5. Highlight and copy the link
6. Paste the copied link (you should now have 2 links, the original and pasted)
7. Return to the Source mode once more to inspect the HTML
8. The HTML markup should look like this:
	<a href="">Link</a></p>
	<a href="../test.html">Link</a></p>
Notice that href has been modified.
I can see (and understand) the Issue now, too.
Indeed the Link is incomplete after Pasting in Source Mode.
As Comparison: Opera 11 and Google Chrome 9 resolve complete Links in Step 7.
OK, I read comment 6 and the rest of the comments in this bug over and over again, and I think we're using different terminology, which has been the source of confusion for me in this bug.

What "resolved target" means is the ultimate location that a link points to, given the value of the href property of the <base> tag, or the document URI if the base tag is not present.

For example, let's say you're in an HTML document with this URI: http://host/path/to/foo.html.  If you have this tag in your document:

<a href="../bar.html">bar</a>

The resolved target of the link would be http://host/path/bar.html (i.e., that's where you would go if you clicked on the link).  "../bar.html" is the specified target for the link.

We relavitize the links when pasting or dropping on purpose, to make sure that the links would be useful on another domain as well.  And the resolved target (with the above definition) is correct, so as far as the links working (or the images being fetched and displayed properly, etc) is concerned, the two forms of the links (absolute and relative) are equivalent.  Is there any reason why this causes problems for you?
I can understand the desire to preserve pasted content between domains, but this kind of support goes beyond basic copy & paste functionality. The browser cannot know how the document being edited will be viewed and should not make the assumption that relativized links will be better or even work. It is up to the containing application to manage how links are altered. 

So, in the example provided in comment 6, if the saved document was viewed through a different url, the copied link will be broken but the original will remain unaffected. 

The browser should preserve the original link as it is, this is the only reasonable approach that the browser can take.
I need to think more about the different implications of going either way...
Whiteboard: [post-2.0]
Is there any update on this issue?
(In reply to comment #11)
> Is there any update on this issue?

I will hopefully pick it up after Firefox 4.0 is released.
Customers are affected by this change that seems to have been introduced in 3.6.11. It is a serious issue, how can we elevate the priority?
I've just encountered this too, I think our use cases reinforces Damians point that it is up to the containing application to manage how links are altered. 

We're using a javascript wysiwyg HTML editor to write HTML emails. All of the  buttons in the editor write absolute links. When a user pastes in content from previous mails, Firefox relativises those links which looks fine in our on screen preview but not when the email is sent.
With the TYPO3 ( CMS's own Editor "htmlarea",there seems to be the same problem.

A link looked like this before being copied/pasted:
<a href="" class="internal-link">lorem</a>

And like this after the action
<a href="" class="internal-link">lorem</a>

More here
To address Ehsan from comment 3: The bug here is that Firefox is breaking the composition of HTML emails. HTML emails require absolute links, but here absolute links to being given to Firefox, and they are silently being turned into relative links.

To add to the tragedy, the links will appear to work in the e-mail composition tool, because the relative links work in the context of page where the email is being created. Only if you view the source carefully will notice there's a problem before you unfortunately send out broken links to hundreds or thousands of people.

I'm not aware of a standard that applies here, but from the comments above, it sounds like Opera and Chrome preserve the absolute links, so in the absence of a standard, consistency would be good.
What is the document URI of the document which is used for HTML mail composition?
The choice to relavitize causes major problems (broken links) when using Firefox to manage a CMS installation.  Our CMS is installed with a base url of /help/  When pasting a URL such as, Firefox instead changes it to ../article-name/  When viewing my new post at, the relative and absolute URLs resolve to the same place.  However, it also has category pages which load at a URL like /help/c/my-category/ and show all the posts in the category.  When one of those posts is new-post, we now have a relative link that resolves to

This is a severe enough problem for our team that anyone working with the CMS will need to use a different browser.
OK, I've thought a lot about this.  I think there is no way for us to get every possible case right with relative URLs, especially in presence of <base> elements.  Therefore I'd like to propose to remove the relativizing behavior upon pasting altogether.  roc, what do you think?
Attached patch Patch (v1)Splinter Review
Assignee: nobody → ehsan
Ever confirmed: true
Attachment #584871 - Flags: review?(roc)
Whiteboard: [post-2.0]
Try run for da3ec20134df is complete.
Detailed breakdown of the results available here:
Results (out of 207 total builds):
    success: 181
    warnings: 26
Builds (or logs if builds failed) available at:
Closed: 13 years ago
Resolution: --- → FIXED

What releases is this fixed in?
Should've been for 12, i.e. on Aurora right now:
See also for comparing the Checkin Dates in Bug Reports with the Version Bump on central.
You need to log in before you can comment on or make changes to this bug.