593053 - [Midas] Editor inserts copied image with full path instead of relative

Status: RESOLVED INVALID

(Core :: DOM: Editor, defect)

Description

[Daniel Kirsch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100826

In my editable doc I have an <img> element with a relative path.

<img src="pictures/img.png">

When I copy that image (CTRL+C) and paste it (CTRL+V) into the doc the pasted code contains the full path to the image instead of the relative one:

<img src="file:///C:/temp/pictures/img.png">

When checking the document.body.innerHTML the original image still has the relative URL.

Reproducible: Always

Actual Results:  
relative img URL is changed to an absolute URL.

Expected Results:  
The pasted html should be identical with the copied.

Comment 1

[Daniel Kirsch]

Some maybe related bugs which also complain about automated conversion (but from absolute to relative):

bug 192945
bug 295930
bug 317538

Comment 2

[(no longer active)]

Why would you want the relative URL over an absolute one?

Comment 3

[Daniel Kirsch]

(In reply to comment #2)
> Why would you want the relative URL over an absolute one?

The original URL is relative "pictures/img.png" and works no matter where my project is copied to. The pasted URL has an absolute URL - in this case to a local resource "file:///C:/temp/pictures/img.png".
When I now put the project online or send it to a collegue, the resource cannot be found anymore while the relative URL still works.

I want and expect the pasted string to be identical with the original copied string.
This might be changeable in a pref or with a midas command for backwards compatibility, but I don't see any reason why my copy should be different from the original.

Comment 4

[Daniel Kirsch]

My current workaround:

document.addEventListener("paste", function(e) {
	var newData = Clipboard.correctAbsolutePath();
	if (newData != null) {
		document.execCommand("inserthtml",false,newData);
		e.preventDefault();
	}
},true);

var Clipboard = {

service : Components.classes["@mozilla.org/widget/clipboard;1"].getService(Components.interfaces.nsIClipboard),

hasFlavor : function(flavor) {
	if (typeof flavor == "string")
		var flavorArray = [flavor];
	else if (flavor instanceof Array)
		flavorArray = flavor;
	else
		throw "WRONG_ARGUMENT_TYPE";

	var clip = this.service;
	return clip.hasDataMatchingFlavors(flavorArray, flavorArray.length, clip.kGlobalClipboard);
},

getTransferable : function() {
	return Components.classes["@mozilla.org/widget/transferable;1"].createInstance(Components.interfaces.nsITransferable);
},

correctAbsolutePath : function(flavor) {
	if (!flavor)
		flavor = "text/html";
	if (!this.hasFlavor(flavor))
		return null;

	var clip = this.service;
	var trans = this.getTransferable();
	trans.addDataFlavor(flavor);
	clip.getData(trans, clip.kGlobalClipboard);

	var str = {};  
	var strLength = {};  
	trans.getTransferData(flavor, str, strLength);  
	if (str)
	  str = str.value.QueryInterface(Components.interfaces.nsISupportsString);  

	var val = str.data;
	val = val.replace(/(<img.?src="|')(file:\/\/\/.*?)("|')/gi,function(a,b,c,d) {
	  return b + getRelativeURL(c) + d;
	}); 

	if (val != str.data)
	  return val;
	return null;
}
};

function getRelativeURL(path) {
	var base = document.baseURI.toLowerCase();
	if (path.toLowerCase().indexOf(base)==0)
		path = path.substring(base.length);
	return path;
}

Comment 5

[(no longer active)]

(In reply to comment #3)
> (In reply to comment #2)
> > Why would you want the relative URL over an absolute one?
> 
> The original URL is relative "pictures/img.png" and works no matter where my
> project is copied to. The pasted URL has an absolute URL - in this case to a
> local resource "file:///C:/temp/pictures/img.png".
> When I now put the project online or send it to a collegue, the resource cannot
> be found anymore while the relative URL still works.
> 
> I want and expect the pasted string to be identical with the original copied
> string.
> This might be changeable in a pref or with a midas command for backwards
> compatibility, but I don't see any reason why my copy should be different from
> the original.

When you copy a piece of HTML, we put some information on the clipboard about the source document's URL.  When the HTML code is pasted into the editor, we use that information to figure out where the HTML snippet has come from, and we convert relative links in the inserted HTML snippet to absolute ones.  The reasoning behind this is that if you copy something from another web page (including an image for example) and paste it into yours, you probably expect the image to show up.  If we don't convert relative URLs to absolute URLs, the image would appear broken.  Therefore, not converting URLs to their absolute form is not what users would expect in 99% of the cases.

That being said, I understand that for some cases, like the one you mentioned, you may prefer relative URLs, but this is not something that the browser can decide on your behalf.  What if in this very application, the user pastes some HTML coming from another website which is not under your control?  I think that if you want some URLs to be relative, you should do the conversion manually after the fact.

Comment 6

[Daniel Kirsch]

Ehsan, thanks for the explanation. This makes total sense to me. But inserting a "file:///" url is probably wrong in most cases.
I still would like to see a setting or command which may at least try to use a relative URL.
In may workaround I use document.baseURI for this. If the defined baseURI is also part of the img URL I strip that part off.
IMHO this is an issue for all local editors including NVU and similar apps.

My current workaround seems to fix the issue for me but I don't really like those "hacks".

Comment 7

[(no longer active)]

(In reply to comment #6)
> Ehsan, thanks for the explanation. This makes total sense to me. But inserting
> a "file:///" url is probably wrong in most cases.
> I still would like to see a setting or command which may at least try to use a
> relative URL.
> In may workaround I use document.baseURI for this. If the defined baseURI is
> also part of the img URL I strip that part off.
> IMHO this is an issue for all local editors including NVU and similar apps.

Have you tested what other browser engines do here?  We can certainly add a new command (like the "use css" command) but that would be proprietary to Gecko, and will probably not benefit the web a lot because of that...

Comment 8

[Kathleen :Brade]

It's been a long time... there is an API that can be hooked into to make changes like this.  Look for: nsIClipboardDragDropHooks.idl.
(If you are concerned about paste, don't forget about drop.)

I don't think that this API works with web pages (Midas) though.

Daniel (comment 6) -- Composer (and probably NVU) relativize links and images when the user saves or uploads them.  See nsIWebBrowserPersist.idl.

Comment 9

[Daniel Kirsch]

Thanks Kathleen, good hints!
I need it for a Midas implementation, however it's in a chrome environment so in my case this might be usable.

Comment 10

[(no longer active)]

Daniel, did you try using nsIClipboardDragDropHooks?  I think this bug should be resolved as invalid.

Comment 11

[Daniel Kirsch]

Ehsan, I havn't tried nsIClipboardDragDropHooks yet. I took a short look at the docs but don't see a real advantage from using it compared to what I currently do in my workaround (see comment 4).

As it's the wanted behaviour you may mark it as invalid. However I still wish to see a kind of setting, command or pref. But this might be a different report marked as enhancement. I still need to check other browser's implementation.

Comment 12

[(no longer active)]

I'm all for having an API which is usable on at least two of the major browsers.  Such an API doesn't exist in any other browsers AFAIK.

By resolving this bug as INVALID, I meant the behavior described in comment 0, which, as I explained in comment 5, is the intended behavior.  Or, we can morph this bug to be about adding the new API if other browsers do support such an API...

Comment 13

[Daniel Kirsch]

Marked invalid due do intended behaviour.
I will file a new enhancement bug if I've tested other implementations and still feel like we should have such a feature.