57228 - Drag text to location bar should replace current contents

Status: RESOLVED WONTFIX

(SeaMonkey :: Location Bar, enhancement)

Description

[Ben Ruppel]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001018
BuildID:    20000101808

Mozilla has the kewl feature that if you select text, you can then click on the
selection and drag it to the url bar, which pastes it there.  The problem is,
chances are that pasting anything (eg: a non-hyperlinked location on a web site)
in this manner is going to be useless when it is placed behind your current
location.  Tedious editing is required, defeating the benefits of the feature.
I suggest that the current contents of the location bar be replaced with
whatever is dragged there.

Reproducible: Always
Steps to Reproduce:
Select some text.  Click on selected area and drag to urlbar. (doesn't work on
with all text (preformatted?))



Actual Results:  Selected text is inserted wherever it was dropped.

Expected Results:  Current contents are replaced by dropped text.

Comment 1

[Asa Dotzler [:asa]]

over to XPApps.  This would indeed be a cool little feature. 

Comment 2

[Blake Ross]

Well, let me know if you want me to do it.  I'm not sure how good it is to 
change the dnd behavior of one special textfield, but then, the URL bar is 
unique in other ways as well.

Comment 3

[Ben Ruppel]

I think it would be great if he did it.  Who's in charge or this anyway? :)

Comment 4

[Matthew T (active 1999-2002)]

Yes, do it! The 99.9 percent case is wanting to open the URL represented by the
dragged text, not to paste the text into the middle of the existing URL. (This
is especially important since plugins swallow drag events, so you can't drag
text or a link into the content area itself (in order to load the URL) if the
content area is owned by a plugin. You need to drag it to the location field
instead.) You don't just want to replace the current contents of the location
field, you want to actually load the URL too.

Hmmm. Actually, there should be a general `drop' attribute of any widget
(including <box>es) indicating what (if anything) can be dragged and dropped
onto that widget. Then we can have a stylable :drop selector for when we drag
something over a widget which has the `drop' attribute set to anything other
than "" (helping solve bug 44269 in the process).

Then the location field could have drop="file,text/plain", so it would accept
dragged links/icons/shortcuts/whatever, and dragged text (but not dragged
pictures, or dragged dragged sounds, and dragged colors would get automatically
converted to the #RRGGBB equivalent, etc etc). Once the Command Toolbar and
Location Toolbar become separate items, however, the Location Toolbar as a whole
could have drop="file,text/plain", and the location field could have drop="none"
(overriding the usual drop="text/plain" of text fields) so as not to override
the drop of its parent. So then you could drag text to *any* part of the
Location Toolbar in order to load that URL.

Comment 5

[Blake Ross]

Hrm, I think that plan requires a bit more work that doesn't quite fall within 
the scope of this bug :)  You might want to start with a bug to make "drop" an 
attribute of all widgets, and then annoy pink about doing the policy work.

Meanwhile, I'll go ahead with the idea originally reported here.

Comment 6

[timeless]

Please don't 'fix' this.

Instead make it possible to drop urls onto other things, like the location 
proxy or general chrome.

I have uses for dragging text into urls. especially w/ bonsai, lxr, ..

Comment 7

[Matthew T (active 1999-2002)]

... And there's the other 0.1 percent. :-)

The problem with allowing dragging onto `general chrome' instead is that you have 
to be careful that you don't drag onto any of the exceptions (where dragging a 
link does something else): the location field, the Personal Toolbar, the Home 
button (assuming that one day it won't be on the Personal Toolbar), the Bookmarks 
button (ditto), and the sidebar (since that should add the page as a sidebar 
panel).

Comment 8

[Blake Ross]

ummm...removing [DONTFIX] because you'll have to do more than that to get a bug 
WONTFIX'd

Comment 9

[sairuh (rarely reading bugmail)]

over to tpreston for qa...

Comment 10

[Blake Ross]

Very interested in doing this.

Matthew, please file a separate bug to me to make dropping an url on the 
sidebar add the page as a panel.

Comment 11

[Matthew T (active 1999-2002)]

I didn't file such a bug, for three reasons.
(1) Someone dropping an URL into a window might very well drop it into the
    sidebar by mistake.
(2) XUL sidebar panels might be able to accept drag-and-drops of URLs themselves
    for various purposes (e.g. Bookmarks), and specifying a global drop behavior
    for the sidebar would be nastily inconsistent with that.
(3) Web pages are (99 percent of the time) so large that they would be unusable
    as sidebar panels anyway.

So I filed bug 60655 instead, and see also bug 28605.

Comment 12

[Ben Ruppel]

As a corollary, dragging an url from, say, the bookmark manager also just
inserts the URL text, where it would be the more favorable behavior to have the
URL replace the current text there.  Guess I should file another bug...

I know this isn't a major feature, but it's one of those little, smart things
that makes one appreciate an application.

Comment 13

[Blake Ross]

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

Comment 14

[Blake Ross]

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

Comment 15

[Blake Ross]

--> urlbar

Comment 16

[Claudius Gayle]

this bug also produces annoying behavior where if you start to drag the url
(proxy icon) and change your mind and drop it back (the only safe place where
nothing should happen) you now get the url inserted into the middle of itself.

Comment 17

[timeless]

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

Comment 18

[Andy Edmonds]

Nominating... 

Primary Heuristic: Prevent User Error!

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

taking bug

Comment 20

[Christian :Biesinger (don't email me, ping me on IRC)]

note to self: see extensions/inspector/resources/content/jsutil/xul/DNDUtils.js#102
for how to do d&d stuff

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

I have learned that UI patches are not wanted in this project. reassigning to
default owner.

Comment 22

[Michael Lefevre]

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

Comment 23

[Jason Bassford]

Breaking convention and duping to a higher numbered bug since there is a patch
under review for it there already.

*** This bug has been marked as a duplicate of 176675 ***

Comment 24

[Jason Bassford]

Ack!  Bug 176675 is Phoenix specific.  My bad.

Comment 25

[Tim Powell]

While it's not the same thing as described in this bug, Mozilla and Mozilla
Firefox support dragging URL text to the Go button to visit that URL. So if
there's a URL on the page that isn't linked, you can select it and drag it to
the Go button. Dragging links to the Go button is also supported by IE.

Comment 26

[Norbert]

(In reply to comment #25)

>Dragging links to the Go button is also supported by IE.

Mozilla also supports dragging links to the Go-button, not only URL-text.

Comment 27

[Norbert]

(In continuation to comment #26)

I have tested Firefox. But I guess "normal" Mozilla also supports this.

Comment 28

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 29

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 30

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 31

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 32

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 33

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 35

[Norbert]

Cannot reproduce this bug in current Firefox (3.6) builds anymore.

Comment 36

[Philip Chee]

WONTFIX. You can drag the url/text on to the Go button.