With the removal of the protocol (http:// and ftp://) from the location bar, it's no longer possible to drag a valid URL out of the location bar and drop it into another application. Since copy operations from the location bar (as long as the selection includes the first character) do prepend the protocol to the page address in order to make a valid URL, the same behavior should be extended to drag and drop operations. An use case affected by this regression would be loading the current page into another browser or pasting the current URL to a text document, without dirtying the clipboard. Some applications (for instance, Safari for Mac) require a string to be a valid URL in order to become drop targets for a text selection, and the lack of the protocol handler makes them fail to accept the drag and drop operation. Chrome doesn't show the issue, and correctly prepends http:// when dragging the current URL out of the location bar, so that other applications can accept it as a valid URL.

WFM on: Mozilla/5.0 (Windows NT 5.1; rv:8.0a1) Gecko/20110710 Firefox/8.0a1 I am able to drag and drop a valid http:// URL out of the location bar and drop it into another application. Reporter, please can you confirm whether this issue still occurs using Firefox in safe mode and/or with a clean profile? http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Basic+Troubleshooting#w_8-make-a-new-profile

Already tried a clean profile and Safe Mode, it still doesn't work. Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110710 Firefox/8.0a1 Steps to reproduce (from a clean profile): 1: Make sure browser.urlbar.trimURLs is set to true (default value) 2: Load an URL (for example, "http://www.mozilla.com/en-US/firefox/new/"). You'll see the trimmed URL in the Location Bar: "www.mozilla.com/en-US/firefox/new" 3: Click on the Location Bar once. The URL will be selected for copy or drag operations 4: Start dragging the URL out of the Location Bar to TextEdit or any other text editor: you'll see the trimmed URL being dragged (expected: you should see the complete URL being dragged) and the "+" green orb will be displayed next to the mouse pointer to show the drop operation will end up in a copy operation and the TextEdit window can accept the dropped data. 5: End the drag operation by dropping the URL to the TextEdit window: the trimmed URL will be pasted in TextEdit (expected: the complete URL should be pasted in TextEdit) Or, better yet: 1, 2, 3: Same as the above 1, 2, 3 steps. 4: Start dragging the URL out of the Location Bar to Safari: you'll see the trimmed URL being dragged (expected: you should see the complete URL being dragged) and the "+" green orb will NOT be displayed to show the drop operation will NOT end up in a copy operation and the Safari window can NOT accept the dropped data (expected: the "+" green orb should be displayed to show the drop operation will end up in a copy operation and the Safari window can accept the dropped data). 5: End the drag operation by dropping the URL to the Safari window or Location Bar: Nothing will be pasted in Safari and the dragged URL will bounce back to its original position (expected: the complete URL should be pasted in the Safari location bar). Please note that I have only tested this on the Mac build, but I expect a similar behavior on Linux and Windows (at least when dropping into a text editor, as I'm not sure whether other browsers than Safari do dragged data validation before advertising themselves as drop areas - if that's even possible in Windows or Linux).

Follow-up to my previous comment #2: I tested it on the Windows build, and I see the exact (buggy) behavior I expected to, in both Aurora and Nightly Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110710 Firefox/7.0a2 Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:8.0a1) Gecko/20110710 Firefox/8.0a1 Steps: 1, 2, 3: Same as the 1, 2, 3 steps in comment #2. 4: Start dragging the URL out of the Location Bar to a text editor (please note that Notepad doesn't support drag and drop, I used SciTE[1] to test it): you'll see the trimmed URL being dragged (expected: you should see the complete URL being dragged) and the "+" white square will be displayed to show the drop operation will end up in a copy operation and the SciTE window can accept the dropped data. 5: End the drag operation by dropping the URL into the SciTE window: the trimmed URL will be pasted in SciTE (expected: the complete URL should be pasted in SciTE). [1]: http://prdownloads.sourceforge.net/scintilla/Sc227.exe

Does it help if you drag the web site image (Favicon) from the left side if the Location bar, instead of the entire URL?

That works, but I'd rather see this fixed for consistency with copy and paste. Aiming to and dragging a 16x16 px favicon isn't the same as dragging a several hundred pixel wide URL (and much less intuitive too).

I have discovered that using Ctrl-C will copy to the clip board and prepend http:// to a URL. Using Ctrl-V will paste the same from the clipboard to any windows program. Using Shift-Del (cut/copy) and Shift-Ins (paste) will cut the text in the URL box but only what you see. It will not prepend http:// to the url. Using Ctrl-C and Shift-Ins will paste the url with http:// prepended if the Ctrl-C was used. Same applies with using right mouse button / copy - will also prepend the http:// I dont know if this is a bug or not without knowing the objective. I personally have used Shift-Del/Shift-Ins for 20 years cutting and pasting text in many programs - Windows/Borland/Word Perfect, etc and they all work. Reproduceble: This works. Open Yahoo.com Click the URL bar and press Ctrl-C Paste into Notepad This does NOT work. Open Yahoo.com Click the URL bar and press Shift-Del Paste into notepad using shift-ins or Ctrl-V

(In reply to Emanuele Alimonda from comment #0) > With the removal of the protocol (http:// and ftp://) from the location bar, > it's no longer possible to drag a valid URL out of the location bar and drop > it into another application. I can confirm that (9.0a1 (2011-08-27)). It is needed for things like Bug 475045 too.

A similar problem is mentioned here: http://forums.mozillazine.org/viewtopic.php?f=38&t=2325047 The difference is that the URL isn't dropped into an external text editor, but into a text area on a web page viewed in Firefox. I have tested drag/drop into Firefox text areas using Fx 7.0 for Windows 7 and using Fx 7.0.1 using Ubuntu 11.04 (32-bit) and both have the same problem. Mac untested, but I'd assume that it behaves the same. Ctrl-C and other key combinations require a clarification. Under Windows (other OSes untested), one "cut" key combination (Ctrl-X) behaves correctly, as do both "copy" key combinations (Ctrl-Ins & Ctrl-C), but the alternative "cut" key combination (Shift-Del) skips http://.

(In reply to Stefan Persson from comment #8) > A similar problem is mentioned here: > http://forums.mozillazine.org/viewtopic.php?f=38&t=2325047 > The difference is that the URL isn't dropped into an external text editor, > but into a text area on a web page viewed in Firefox. See Bug 691711.

i submitted bug 701647 to allow drag operations in general (also not from the location bar) when the leading protocol is missing. perhaps these two bugs should be consolidated?

Unassigned myself for now in case someone else has time to do this.

I think this bug can be marked as fixed

(In reply to ebraminio from comment #13) > I think this bug can be marked as fixed Proof? Because it's not. See Bug 722670.

I don't know, in recent updates of firefox nightlies, seems this bug is fixed please try http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-ux/ you must see something same http://dl.dropbox.com/u/7125981/UX13.png also drop link on download manager (mine is free download manager) has not any problem (bug 722670) so I think these bugs can marked as fixed

Maybe in UX but in the latest Nightly I'm testing (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0a1) Gecko/20120205 Firefox/13.0a1), it's not.

Another testcase of http:// missing when a trimmed URL is copied/pasted from the location bar. STR: 0) Set about:config > browser.urlbar.trimURLs = true 1) Open the thumbnail in another tab (middle click) http://img238.imagevenue.com/get_code.php?loc=loc353&image=795809180_lgjldr01_122_353lo.jpg NB: the central point of the testcase is that the picture is hosted on a slow server of imagevenue.com so the webpage doesn't load immediately. 2) Select the URL and copy it WHEN the webpage is loading 3) Paste the URL in a random textarea or in Notepad Result: The URL is pasted as img238.imagevenue.com/img.php?loc=loc353&image=795809180_lgjldr01_122_353lo.jpg with http:// missing. NB: you can use the testcase I joined too.

I don't think this bug is fixed at all. I still have this problem dragging URLs from Firefox to IM clients, e.g. Google Chat...

We get all kinds of anon content from inside the input field here, and because of the early return added in bug 478070, we break. Just fixing that also fixes this bug.

Marco, can you add this? I'm waiting on needinfos on my two other bugs for this iteration.

(In reply to :Gijs Kruitbosch from comment #21) > Marco, can you add this? I'm waiting on needinfos on my two other bugs for > this iteration.

I'm curious, does your patch fix bug 722670 too?

(In reply to Loic from comment #23) > I'm curious, does your patch fix bug 722670 too? As best I can tell (dragging between windows in the same app in OS X is painful), yes.

Comment on attachment 8479069 [details] [diff] [review] include protocol when dragging URLs from the URL bar, Does compareDocumentPosition work here?

It produces '20' for the anon div inside the inputField. I did check node.contains() before resorting to the loop, but that just returns false, which is an interesting discrepancy... anyway, this seems to work, yeah.

Comment on attachment 8479196 [details] [diff] [review] include protocol when dragging URLs from the URL bar, Please use these consts: http://hg.mozilla.org/mozilla-central/annotate/dc352a7bf234/dom/webidl/Node.webidl#l76 Can event.originalTarget still be the inputField itself?

Thanks Gijs. I've added the bug to the current iteration. (In reply to :Gijs Kruitbosch from comment #22) > (In reply to :Gijs Kruitbosch from comment #21) > > Marco, can you add this? I'm waiting on needinfos on my two other bugs for > > this iteration.

I'm not sure, but let's just not take the risk even if it's fine now (e.g. if it can't currently happen because the anon divs have no margin and inputField no padding, there's no predicting that'll be the same across all platforms forever, and if it changed it'd subtly break this in hard to reproduce cases).

remote: https://hg.mozilla.org/integration/fx-team/rev/0edf9e2cef4c

Verified fixed (double-clicked an http URL, dragged and dropped into GVim with insert mode): bug: 2014-08-26-03-02-03-mozilla-central-firefox-34.0a1.ru.linux-x86_64 wfm: 2014-08-27-03-02-02-mozilla-central-firefox-34.0a1.ru.linux-x86_64

Per comment #32.