323913 - Dragging and dropping links to tab bar does not strip whitespace...

Status: RESOLVED INCOMPLETE

(Firefox :: Tabbed Browser, defect)

Description

[baconputing]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

If you highlight a url that is not a hyperlink, (either because you are viewing a plain text document or the url is simply not wrapped in an <a> tag) and drag it to an empty space on the tab bar, a new tab is opened with the link you selected.  However, if you accidently highlight additional whitespace on either side of the url and drag that to the tab bar, nothing happens.

For example, if you came across a plain text url like http://www.example.com/path/file.ext in a document, highlighted "http://www.example.com/path/file.ext", and dragged the highlighted text to the tab bar, a new tab will be created with that url.  If you were to highlight " http://www.example.com/path/file.ext", "http://www.example.com/path/file.ext ", " http://www.example.com/path/file.ext ", or any other combination of text that includes the link plus leading and/or trailing whitespace, nothing will happen when the highlighted text is dragged to the tab bar.

As a matter of convenience for the user, either of the following two things should happen when highlighted text is dragged to the tab bat:

	A) Leading and trailing whitespace should be stripped from the text before it is used as a url with which to open a new tab.
	B) The browser should attempt to use the highlighted text as a url with which to open a new tab like it currently does.  If the url is invalid and a new tab cannot be created, rather than simply ignoring the drop event (like it currently does), the browser should then attempt to create a new tab using the highlighted text with the leading and trailing whitespace stripped.  If the resulting text *still* represents an invalid url and a new tab cannot be created, *then* the drop event should be ignored.

Reproducible: Always

Steps to Reproduce:
1. Open a document with a plain text url.  (Assuming Bugzilla doesn't automatically convert urls to hyperlinks, you can use the example url provided in the Details section on the page for this bug report.  It doesn't matter if the url points to a non-existant page, just that it's well-formed.)
2. Highlight the entire url plus some adjacent whitespace.
3. Drag the highlighted text to the tab bar.

Actual Results:  
Nothing happens.  No tab is opened and the drop event is apparently ignored.

Expected Results:  
The browser should strip the insignificant whitespace from the url and use that to attempt to create a new tab.

Comment 1

[baconputing]

Ok, apparently Bugzilla *does* convert urls to hyperlinks, however the example urls in my initial post still demonstrate the problem.  If you highlight all or part of one of the hyperlinks and drag it to the tab bar, a new tab is created (although apparently using the hyperlink's href rather than the highlighted text - but that's irrelevant).  If you highlight an entire hyperlink plus some adjacent whitespace and drag it to the tab bar, nothing happens.  So, this problem seems to affect both plain text urls as well as hyperlinks.

Comment 2

[Ria Klaassen (not reading all bugmail)]

Bookmarklet, shows links as text (unknown origin):
javascript:(function(i,j,n,o){if(!document.__links){document.__links=[];with(document){for(i=0;i<links.length;++i){__links.push(n=links[i]);o=createElement('SPAN');n.FLIP=o;o.FLIP=n;for(j=0;j<n.childNodes.length;++j){o.appendChild(n.childNodes[j].cloneNode(true))}}}}with(document){for(i=0;i<__links.length;++i){n=__links[i];n.parentNode.replaceChild(__links[i]=n.FLIP,n)}}})()

Comment 3

[Arie Paap [:wildmyron]]

This would seem to be a dupe of bug 252441

There seems to be some uncertainty about what is the right thing to do.

Comment 5

[Tyler Downer [He/Him]]

This bug was reported using Firefox 3.0 or older, which is no longer supported. The bug has also not been changed in over 500 days and is still in UNCO.
Reporter, please retest this bug in Firefox 3.6.10 or later using a fresh profile, http://support.mozilla.com/en-US/kb/managing+profiles. If you still see this problem, please update the bug. If you no longer see the bug, please set the resolution to RESOLVED, WORKSFORME.

This is a mass search of unconfirmed bugs that have no activity on them, so if you feel a bug was marked in error, just remove the CLOSEME comment in the whiteboard within the next month.

Comment 6

[Tyler Downer [He/Him]]

No reply, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.