Last Comment Bug 613517 - URL is not maintained for links or images after copy/paste in contenteditable
: URL is not maintained for links or images after copy/paste in contenteditable
Product: Core
Classification: Components
Component: Editor (show other bugs)
: 1.9.2 Branch
: x86 Windows XP
-- major with 5 votes (vote)
: mozilla12
Assigned To: :Ehsan Akhgari
: Makoto Kato [:m_kato]
Depends on:
  Show dependency treegraph
Reported: 2010-11-19 09:00 PST by Brian Bermingham
Modified: 2012-02-27 14:14 PST (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Screenshot of the original links in a contenteditable div (222.76 KB, image/jpeg)
2010-11-23 02:18 PST, Brian Bermingham
no flags Details
Screenshot of the original links with a pasted copy of each link, notice the pasted link has been modified (342.76 KB, image/jpeg)
2010-11-23 02:19 PST, Brian Bermingham
no flags Details
Patch (v1) (4.82 KB, patch)
2011-12-29 15:32 PST, :Ehsan Akhgari
roc: review+
Details | Diff | Splinter Review

Description User image Brian Bermingham 2010-11-19 09:00:21 PST
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 -
Comment 1 User image :Ehsan Akhgari 2010-11-20 14:18:08 PST
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?
Comment 2 User image Brian Bermingham 2010-11-21 09:11:12 PST

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
Comment 3 User image :Ehsan Akhgari 2010-11-22 18:37:16 PST
Again, I don't see what the problem is, exactly.  Is the resolved target of the links after the paste operation incorrect?
Comment 4 User image Brian Bermingham 2010-11-23 02:18:16 PST
Created attachment 492600 [details]
Screenshot of the original links in a contenteditable div
Comment 5 User image Brian Bermingham 2010-11-23 02:19:40 PST
Created attachment 492601 [details]
Screenshot of the original links with a pasted copy of each link, notice the pasted link has been modified
Comment 6 User image Brian Bermingham 2010-11-23 09:08:44 PST
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.
Comment 7 User image (mostly gone) XtC4UaLL [:xtc4uall] 2010-11-23 16:30:12 PST
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.
Comment 8 User image :Ehsan Akhgari 2010-11-24 11:54:48 PST
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?
Comment 9 User image Damian 2010-11-25 05:06:57 PST
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.
Comment 10 User image :Ehsan Akhgari 2010-11-25 15:28:46 PST
I need to think more about the different implications of going either way...
Comment 11 User image Damian 2010-12-10 04:21:44 PST
Is there any update on this issue?
Comment 12 User image :Ehsan Akhgari 2010-12-10 11:25:14 PST
(In reply to comment #11)
> Is there any update on this issue?

I will hopefully pick it up after Firefox 4.0 is released.
Comment 13 User image Damian 2010-12-13 04:51:08 PST
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?
Comment 14 User image Dean Sas 2011-07-27 06:41:37 PDT
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.
Comment 15 User image Urs Braem 2011-07-29 07:08:37 PDT
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
Comment 16 User image Mark Stosberg 2011-10-05 10:54:27 PDT
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.
Comment 17 User image :Ehsan Akhgari 2011-10-06 09:25:21 PDT
What is the document URI of the document which is used for HTML mail composition?
Comment 18 User image Bryce Kujala 2011-12-28 23:48:51 PST
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.
Comment 19 User image :Ehsan Akhgari 2011-12-29 14:00:24 PST
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?
Comment 20 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2011-12-29 14:17:51 PST
I agree.
Comment 21 User image :Ehsan Akhgari 2011-12-29 15:32:53 PST
Created attachment 584871 [details] [diff] [review]
Patch (v1)
Comment 22 User image Mozilla RelEng Bot 2011-12-29 19:30:31 PST
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:
Comment 24 User image Phil Ringnalda (:philor) 2011-12-31 19:49:06 PST
Comment 25 User image Brian Bermingham 2012-02-27 06:55:45 PST

What releases is this fixed in?
Comment 26 User image (mostly gone) XtC4UaLL [:xtc4uall] 2012-02-27 14:14:10 PST
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.

Note You need to log in before you can comment on or make changes to this bug.