289513 - drag'n drop selected text url (i.e. no < a > tag) is not working

Status: RESOLVED WORKSFORME

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[Mathieu Pellerin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050402 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050402 Firefox/1.0+

drag and drop of selected text url ceased to work in the trunk (I would estimate
it happened +/- 3 weeks ago).

Reproducible: Always

Steps to Reproduce:
1.select a text url within a paragraph
2.drag and drop that selection either in the location bar or the tab bar

Actual Results:  
nothing happens

Expected Results:  
recognise that the selection is an url and deal with it like a link

Comment 1

[TimoT]

I'm seeing this too. 

Like mentioned in the bug, this is fallout from bug 285438

Comment 2

[Mathieu Pellerin]

Bug 289667 might be another regression from Bug 285438

Comment 3

[Daniel Veditz [:dveditz]]

bug 285438 is still open, only partially fixed. Making this depend on it so we
don't forget. Not blocking 1.0.3

Comment 4

[Rich Walsh]

FWIW... if this is a regression caused by bug 285438, then it is likely in the
Windows-specific changes. The OS/2 version (which didn't require any changes in
its native d&d code) continues to load plain-text URLs.

Comment 5

[Rob Larkin]

Using gentoo and firefox 1.03, I can drag a text url onto the close tab and a
new tab will open, loading that url IF it's a complete url (the http:// MUST be
present). 

In the Mozilla suite I can drag the text "mozilla.org" onto a new tab, but in
firefox, nothing happens.  It only works with "http://www.mozilla.org".

Since there's is obvious parsing going on here, I'm assuming that this behaviour
is intentional, although I really want to call it a bug.  A url in text form
more often than not does not include the "http://".  If I drag text to a tab or
the close tab icon, firefox should attempt to load it.

I hope someone can respond here, should this be a different bug, or a feature
request?

Rob

Comment 6

[Mathieu Pellerin]

it's a regression; it was working in firefox 0.x and 1.0

it's a regression; it's just a clever behaviour that stopped to work :)

Comment 7

[Jaime Mitchell (use [e-mail] for email)]

*** Bug 293920 has been marked as a duplicate of this bug. ***

Comment 8

[Justin Wood (:Callek)]

Requesting Blocking b3, (feel free to make it block b2, but I do not see it as
*that* critical, nor do I know who would have time to fix it for b2)

Comment 9

[Hermann Schwab]

(In reply to comment #7)
> *** Bug 293920 has been marked as a duplicate of this bug. ***

Just want to comment that Bug 293920 can't drop textlink on tabbar
was filed against 1.7 Branch, Firefox 1.0.4 and Mozilla 1.7.8, not against Trunk.
Mozilla Suite trunk is still working.

Comment 10

[Mathieu Pellerin]

okey, I really dont get why Asa removed the blocking flag. That's a _basic_
_broken_ feature...

Enough with the incomprehension, some more information

 this http://www.blabla.com/ (of course plain text, not <a>) will drag'n drop
properly

 while

 www.blabla.com will not

I really hope it'll get fixed, it's just soo annoying

Comment 11

[Hermann Schwab]

*** Bug 294013 has been marked as a duplicate of this bug. ***

Comment 12

[Hermann Schwab]

If you look at the dupes Bug 293920 and Bug 294013:
The bug started Firefox 1.0.2 and still is seen in 1.0.5 and Deerpark
It started Mozilla 1.7.7 but isn´t seen in Mozilla Suite Trunk / Seamonkey.

Dragging www.mozilla.org to the tabbar is working from an external programm,
let's say Notepad.exe, but doesn't work when dragged from a browser window.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b3) Gecko/20050710 Firefox/1.0+
Can't drag www.mozilla.org from browser window to Tab Bar or Location Bar.
Same textlink dragged from Seamonkey browserwindow to Deerpark Location Bar is
loaded, to Deerpark tabbar does nothing.

Error messages:

Error: [Exception... "'Drop of www.mozilla.org denied.' when calling method:
[nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]

Error: uncaught exception: Drop of www.mozilla.org denied.

Comment 13

[Mathieu Pellerin]

Why do you change the version? It's broken in the trunk, please dont give the
impression it's a branch only problem. I would much rather see a fix for gecko
1.8 than 1.7.x ! :)

Comment 14

[Asa Dotzler [:asa]]

we'd consider a patch but not going to block on this.

Comment 15

[Dave Townsend [:mossop]]

*** Bug 301860 has been marked as a duplicate of this bug. ***

Comment 16

[Jesse Ruderman]

Mostly* WFM on trunk.

www.blabla.com            to empty space on tab bar - works
http://www.blabla.com/    to empty space on tab bar - works
chrome://browser/content/ to empty space on tab bar - nothing happens

www.blabla.com            to address bar            - replaces, but doesn't go*
http://www.blabla.com/    to address bar            - works
chrome://browser/content/ to address bar            - nothing happens

Comment 17

[Jesse Ruderman]

Same on the Gecko 1.8 branch.  Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;
en-US; rv:1.8b4) Gecko/20050829 Firefox/1.0+

Comment 18

[Jesse Ruderman]

And the same on Windows (only tested Gecko 1.8 branch, Aug 28 nightly).  WFM.

Comment 19

[Jesse Ruderman]

If I drag trailing whitespace along with www.mozilla.org to the tab bar, it
doesn't work.

Comment 20

[Jesse Ruderman]

Since I can reproduce the original bug (comment 0 / comment 12) using
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050412
Firefox/1.0+ but not using a newer build, marking as WFM.  I haven't tried to
narrow down the unregression(?) window.  I'll file new bugs based on comment 16
and comment 19.

Comment 21

[Jesse Ruderman]

Filed bug 306622 - Dragging URL with trailing whitespace to empty spot on tab
bar does nothing.

Filed bug 306623 - Dragging URL requiring fixup to location bar doesn't go there
immediately.

Comment 22

[:Gavin Sharp [email: [e-mail]]]

*** Bug 309064 has been marked as a duplicate of this bug. ***