161053 - Dragging from another app to URL Bar when editing inserts text, doesn't replace old text

Status: VERIFIED WORKSFORME

(Camino Graveyard :: General, defect, P3)

Description

[Stephane Moureau]

If you drag an url from the page contents to the location field, it inserts it
where you drop it instead of replacing all its contents.
Why? For example on Chimera Board to avoid opening a new page if it's an
external link.
I'm not sure how this should be handled.

Comment 1

[Greg K.]

Confirmed using Chimera/20020801. I'd have to agree that it would be more useful
when drag-and-dropping a URL to select and replace the entire URL Bar contents.
Should we do this all the time? Can we selectively do this under certain
circumstances and not do it under others?

Comment 2

[Lauri Kieksi]

How about just defaulting to replacing the whole location field contents with
the dragged content, and using the alternate behavior (append) if Option is held
down?

Comment 3

[Max Horn]

Why would one ever need the alternative? I can't think of a single example 
where this would be useful, can you? Then please enligten me :--)

IMHO it should just always replace the URL in the location bar (as it does 
in IE and OmniWeb). In fact, both do not just insert the URL, they 
immediatly load it. Not sure if that is a good idea, but I wanted to mention 
it here for completness.

Comment 4

[David Haas (gone, not reading mail)]

I'll comment, because I was confused & made a patch to fix this, then realized
it was really a different thing altogether, so I modified the summary.

The URL bar currently only accepts D&D of text/URL's if it is in the process of
being edited.  If it's not being edited, you can't drop anything on to it (patch
in bug 162791 fixes this)  

If you are editing the URL bar then you see this "bug" - because it's standard
text field behavior to insert text at the caret, rather than replace what's there.  

I can come up with 2 reasons to keep the current behavior.  

1st: it's standard text field behavior.  i don't think this is a good reason, btw :)

2nd: if you were trying to insert a URL from another program (ie, Mail) which
had been broken up into multiple lines such that it was no longer "clickable",
and you wanted to get Chimera to load that URL, the current behavior would let
you select each line of the URL & drag it in to the appropriate place in the URL
bar, then hit enter to load the URL when it was done.  If you erase & replace on
D&D, you wouldn't be able to do that: you'd either have to type the URL in by
hand or use another program to copy & paste the lines together, then copy that
single line into Chimera.  It's obscure, but I think a valid reason.

I think changing this to always erase what's in the URL bar would be
straighforward - just override performDragOperation in the field editor.  If the
masses demand it, I'll make a patch.

Comment 5

[Mike Pinkerton (not reading bugmail)]

hmmmm

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

WFM 20050419 (0.8+)

Dragging a URL to the location bar always replaces the existing contents of the
location bar rather than inserting in the middle of the existing contents.

Comment 7

[Wevah (Nate Weaver)]

(In reply to comment #6)
> WFM 20050419 (0.8+)
> 
> Dragging a URL to the location bar always replaces the existing contents of the
> location bar rather than inserting in the middle of the existing contents.

Not when you're currently editing the location bar and you drag text in from
another application.

Comment 8

[Wevah (Nate Weaver)]

Of course, maybe we want this behavior...

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #7)

> Not when you're currently editing the location bar and you drag text in from
> another application.

Ah, I was always hitting the far right end of the location bar with my drags
from elsewhere.  Oops.  It definitely should do the same thing no matter where
the drag lands, and I'd say no matter where the drag originates, too.

If one does have a problematic/broken URL in another app (i.e. comment 4 case
2), copy-paste seems like a more logical (and sane) approach than trying to drag
piece after piece.

The location bar should really behave the same way all the time and on both of
its ends, IMHO :-)

Comment 10

[Samuel Sidler (old account; do not CC)]

Updating summary to reflect bug per comment 7.

Comment 11

[Chris Lawson (gone)]

Adding [good first bug], assigning back to default. Pink, if you really want this,  feel free to take it again, but I didn't think you were working on it, and some of our new guys might want to tackle this as a fairly simple first bug.

cl

Comment 12

[Peter Jaros (:peeja)]

Don't see this on 2006123004 (1.1a1+).  Fixed at some point?

Comment 13

[Shannon Harvey]

(In reply to comment #12)
> Don't see this on 2006123004 (1.1a1+).  Fixed at some point?
> 

Camino Version: 2007052622 (1.6a1pre)

I also tested this behavior between TextEdit and Camino and found the existing url was replaced (not appended to).  This bug does appear to be have been fixed. 

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

WFM with 1.5rc2, too.