Closed Bug 289513 Opened 20 years ago Closed 19 years ago

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

Categories

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

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: nirvn.asia, Assigned: jruderman)

References

Details

(Keywords: regression)

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
Keywords: regression
I'm seeing this too. Like mentioned in the bug, this is fallout from bug 285438
Bug 289667 might be another regression from Bug 285438
Flags: blocking-aviary1.0.3?
Assignee: firefox → jst
Status: UNCONFIRMED → NEW
Ever confirmed: true
bug 285438 is still open, only partially fixed. Making this depend on it so we don't forget. Not blocking 1.0.3
Depends on: 285438
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.3?
Flags: blocking-aviary1.0.3-
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.
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
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 :)
*** Bug 293920 has been marked as a duplicate of this bug. ***
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)
Flags: blocking1.8b3?
Component: General → Drag and Drop
Product: Firefox → Core
Version: unspecified → Trunk
(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.
Assignee: jst → mconnor
Flags: blocking1.8b4?
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1?
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
*** Bug 294013 has been marked as a duplicate of this bug. ***
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.
Version: Trunk → 1.7 Branch
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 ! :)
Version: 1.7 Branch → Trunk
we'd consider a patch but not going to block on this.
Flags: blocking1.8b4? → blocking1.8b4-
*** Bug 301860 has been marked as a duplicate of this bug. ***
Assignee: mconnor → jruderman
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
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+
And the same on Windows (only tested Gecko 1.8 branch, Aug 28 nightly). WFM.
If I drag trailing whitespace along with www.mozilla.org to the tab bar, it doesn't work.
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
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.
*** Bug 309064 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.