76010 - middle-mouse paste over selection adds to selection instead of overwriting it

Status: RESOLVED DUPLICATE of bug 289757

(Core :: DOM: Selection, defect, P3)

Description

[sairuh (rarely reading bugmail)]

not sure if this belongs in the URLbar component, or in selection... occurs
using a linux debug from noon today, as well as 2001.04.12.08 verif bits.

0. make sure the cursor isn't in the URL bar --eg, have focus in the content of
a page like http://mozilla.org
1. drag to select [highlight] some content in the page --eg, the
"mozilla.party.jp 2.0" header in bold.
2. hit accel+L [ctrl+L in my case] to go to the URL bar and select its contents.
3. middle-mouse paste into the URL bar.

result: the copied selection is appended to what's currently in the URL bar, ie,
"http://mozilla.org/mozilla.party.jp 2.0"

expected: "http://mozilla.org/" should be overwritten.

Comment 1

[sairuh (rarely reading bugmail)]

this also occurs when i've copied a link [eg, use Copy Link Location from
context menu from a browser window or even a mailnews window] and want to paste
it in the URL bar.

Comment 2

[Alec Flett]

this is an issue in all text fields, not just the url bar...

Comment 3

[Akkana Peck]

Alec, could you elaborate on what the bug is as it applies to other text fields?
 The description so far only applies to the urlbar (since that's the only text
field you can go to and "highlight but don't copy the whole thing" by hitting
accel-L.  Are you saying that if you select something in a text field then
middlemouse paste in the same text field, it should overwrite the selection
instead of inserting at the location of the mouse click?  I tried a couple other
Unix apps and other apps behave as we do (insert at mouse position, even if
something was previously highlighted).

It doesn't seem like we should change the behavior for ordinary text fields,
since we seem to be doing the same thing as other apps.  For the urlbar, we
could consider doing something different, since the accel-L behavior is already
a weird case.

Comment 4

[Alec Flett]

all I meant was that if this is the desired behavior (as reported by sairuh)
then the behavior is specific to the text-field widget, it's nothing I know how
to fix in the FE...

Comment 5

[rubydoo123]

this also seems to be linux only, following the same steps on win32 and Mac and
it works correctly

Comment 6

[anthonyd]

ccing: blake, ben goodger, jag, and hewitt on this:
requested behavior is specific behavior for the url bar (middlemouse pasting 
replacing url) to do this correctly, it needs to be done BEFORE the 
EditorEventListeners.  Jag suggested implementing this in the XBL handlers or 
the URL bar widget.

reassigning to blake because he knows his way around the xbl very well.

Comment 7

[Blake Ross]

changing selection qa to tpreston.

Comment 8

[rubydoo123]

removing myself from the cc list

Comment 9

[Moritz Winter]

Different Solution:

Just add a delete Button to the URL-Bar, like they did in KDE Konqueror, so
before cut & pasting the user has to press "delete", for me this seems to be a
very good feature of Konqueror.

Comment 10

[Jesse Ruderman]

I think this should be fixed for all text fields unless someone can convince me
that the behavior of other linux apps makes sense.

Comment 11

[Jesse Ruderman]

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

Comment 12

[Akkana Peck]

Jesse: It makes sense -- it's consistent with how copy/paste works everywhere
(and it makes it possible, for example, to select a word and paste that word
somewhere else in the same text control, which would become impossible if you
"fixed" this).  

Middlemouse pastes at the location of the mouse, in every unix app.  I could see
replacing the selection if the mouse was over the selection (which for any text
widget except the urlbar would be a nop, since it would replace the selection
with the selection), but replacing the selection when the mouse cursor is
located somewhere else, like after the end of the url, would be completely
unexpected behavior and very unlike any other app.

Comment 13

[Jesse Ruderman]

Good point, this needs to check whether you're pasting over the selection or
somewhere else in the text field.  That's how context-menu paste works in text
fields in web pages in IE 6.

I don't think this bug is only for the address bar.  Javascript prompts, for
example, should have their initial text selected (bug 62880) so that you can
ignore the initial text and type your own immediately, but that text must not
automatically become the primary selection for security reasons.  Single-line
text fields will become selected when you tab to them (bug 28583), maybe even on
Linux.

Comment 14

[David Mediavilla]

This also happens in OS/2 if I have the corresponding pref enabled. I think this
should work like the Paste option in the context menu. It goes against OS/2 UI
expectances to select something in a text box (like this Additional Comments)
and when pasting not seeing it replaced. Middle-button pasting is not common in
OS/2 but now that I found about it, I'd like it to work consistent with other
Paste options.

Comment 15

[Klaus Kusche]

I'm also bitten by that problem when pasting URL's into the main URL text field
by middle-clicking: It get's inserted into the existing text instead of
overwriting it.

The same problem is true for the URL open dialog which comes up when you open
another browser window from the command line: The dialog comes up with the last
URL preselected in the URL text field, but middle-clicking inserts/appends the
new URL to the old one instead of replacing it.

Comment 16

[Ria Klaassen (not reading all bugmail)]

Duplicate of bug 289757 or is there something between the lines that I missed and makes it a different case?