Closed Bug 613517 Opened 14 years ago Closed 13 years ago

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

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Version:
1.9.2 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla12

People

(Reporter: u218732, Assigned: ehsan.akhgari)

Details

Attachments

(3 files)

Screenshot of the original links in a contenteditable div
222.76 KB, image/jpeg
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
Details
Patch (v1)
4.82 KB, patch
roc
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) 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:1.9.2.12) 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 http://firefox.com/foo/bar/bug.html, the following links:
<a href="http://firefox.com/foo/test.html">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 http://www.firefox.com/foo/bar/car/copypaste.html
2. Add a contenteditable div with some absolute and relative links and images e.g. 
<div contenteditable="true" id="contentArea">
	<a href="http://www.firefox.com/foo/bar/test.html">Link1</a>
	<br><br>
	<img src="http://www.firefox.com/foo/bar/test.jpg">
	<br><br>
	<a href="/test.html">test.html</a>
	<br><br>
	<a href="/foo/test.html">/foo/test.html</a>
	<br><br>
</div>

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>
	<br><br>
	<img src="../test.jpg">
	<br><br>
	<a href="../../../test.html">test.html</a>
	<br><br>
	<a href="../../test.html">/foo/test.html</a>
	<br><br>
</div>

Expected Results:  
After paste, href/src urls should be the same as the original content
i.e.
<div contenteditable="true" id="contentArea">
	<a href="http://www.firefox.com/foo/bar/test.html">Link1</a>
	<br><br>
	<img src="http://www.firefox.com/foo/bar/test.jpg">
	<br><br>
	<a href="/test.html">test.html</a>
	<br><br>
	<a href="/foo/test.html">/foo/test.html</a>
	<br><br>
</div>

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:
https://bugzilla.mozilla.org/show_bug.cgi?id=599322

This is related to editing in a rich text area, e.g CKEditor - http://ckeditor.com
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 <http://www.firefox.com/foo/bar/car/copypaste.html>, they look correct to me.

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

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:
<html>
	<head>
		<title>Copy / Paste in Firefox</title>
	</head>
	
	<body>
		<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>
		</div>
	</body>
</html>

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:
http://nightly.ckeditor.com/6110/_samples/ajax.html
This is a better demo page to use than http://ckeditor.com/demo 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="http://nightly.ckeditor.com/6110/test.html">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. "http://nightly.ckeditor.com"
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:
<p>
	<a href="http://nightly.ckeditor.com/6110/test.html">Link</a></p>
<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 (http://www.typo3.org) CMS's own Editor "htmlarea",there seems to be the same problem.

A link looked like this before being copied/pasted:
<a href="http://example.ch/?id=27#39" class="internal-link">lorem</a>

And like this after the action
<a href="http://example.ch/../?id=27#39" class="internal-link">lorem</a>

More here http://forge.typo3.org/issues/28497
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 http://www.domain.com/help/article-name/, Firefox instead changes it to ../article-name/  When viewing my new post at http://www.domain.com/help/new-post, 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 http://www.domain.com/help/c/article-name/

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
Status: UNCONFIRMED → ASSIGNED
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:
    https://tbpl.mozilla.org/?tree=Try&rev=da3ec20134df
Results (out of 207 total builds):
    success: 181
    warnings: 26
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/eakhgari@mozilla.com-da3ec20134df

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/0609a69f85a6
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED

    
    

    
  
@Ehsan,

What releases is this fixed in?

    
    

    
  
Should've been for 12, i.e. on Aurora right now: http://www.mozilla.org/en-US/firefox/aurora/
See also https://wiki.mozilla.org/RapidRelease/Calendar 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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: