Closed Bug 289757 Opened 20 years ago Closed 17 years ago

paste on middle click does not take into account existing selection

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ispiked, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

When you try to paste something into a form with already highlighted text with
the middle mouse button it does not delete the previous string of text and
insert the text from the clipboard. It instead inserts the string from the
clipboard into the highlighted string.

Reproducible: Always

Steps to Reproduce:
1. Make sure you have a string of text on the clipboard.
2. Type something into a form field.
3. Highlight it (either with triple click or by dragging the mouse over it).
4. Middle click on the highlighted text.

Actual Results:  
The text from the clipboard is inserted into the highlighted text.

Expected Results:  
Removed the highlighted text and inserted the new text.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050409
Firefox/1.0+


Middleclick does nothing for me.
Only rightclick does (contextmenu)

May this be extensionrelated ?
(In reply to comment #1)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050409
> Firefox/1.0+
> 
> 
> Middleclick does nothing for me.
> Only rightclick does (contextmenu)
> 
> May this be extensionrelated ?

I forgot to mention that you must have middlemouse.paste set to true in
about:config. 

This could be related to an extention (mouse gestures?) but I had a friend test
it and he got the same result without any special extentions installed.


Also happens with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2)
Gecko/20050404 Firefox/1.0+

I didn't even know you can paste like this...
->NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050401 Firefox/1.0.2
(Debian package 1.0.2-2)

I can confirm this bug for Linux (Debian) as well. I guess it's platform
independent.
The middle click paste code isn't aware of existing selections.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/editor/libeditor/text/nsEditorEventListeners.cpp&rev=1.233#303
Assignee: firefox → mozeditor
URL: http://bonsai.mozilla.org/cvsblame.cg...
Component: General → Editor
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → bugzilla
Hardware: PC → All
Summary: paste on middle click does not work as expected → paste on middle click does not take into account existing selection
Version: unspecified → Trunk
Middle-click should simply paste at the mouse cursor location.  _Maybe_ if
that's inside the existing selection the selection should be replaced.  But in
general, this should NOT replace the existing selection.
(In reply to comment #7)
> Middle-click should simply paste at the mouse cursor location.  _Maybe_ if
> that's inside the existing selection the selection should be replaced.  But in
> general, this should NOT replace the existing selection.

Right, I would only expect the selection to be replaced if that's where you're
pasting. Is that not the standard behavior for middle click paste in other apps?
There is no standard behavior.  OpenOffice never replaces; if you paste on top
of the selected stuff it ignores your paste attempt; if you pasted outside it,
it inserts at mouse pointer.  Gnumeric (and possibly other GNOME apps?) replaces
the selected text no matter where the mouse pointer is (which makes very little
sense, imo).   Opera does what Mozilla does right now.  Konqueror (and other KDE
apps?) simply forgets its selection completely if I select something in a
different window, so the situation cannot possibly arise.
(In reply to comment #7)
> Middle-click should simply paste at the mouse cursor location.  _Maybe_ if
> that's inside the existing selection the selection should be replaced.  But in
> general, this should NOT replace the existing selection.

I see where you're coming from, but considering that when you paste text into
other text when it's NOT highlighted it already does this, wouldn't it make
sense to have it replace the text when the selection IS highlighted? It seems
stupid to have it do the same thing both when it's selected AND when it's not.
Generally, doing the same thing for the same user action is considered a good
thing in UI design from what I understand... principle of least surprise and
all.  In other words, why are you assuming the user purposefully highlighted
some text, then copied text in another app and then pasted (as opposed to just
accidentally highlighting text at some point, as a lot of people just sort of do
with mice, and then at a later point pasting something into that window)?
*** Bug 320754 has been marked as a duplicate of this bug. ***
"doing the same thing for the same user action is considered a good
thing in UI design from what I understand... principle of least surprise and
all"

Yes; when I select text and hit paste, I expect the text to be replaced, such as with Ctrl-V or edit->paste.  When commanding a paste through a middle-click, I expect the same behavior.  Why should middle click paste behave differently than edit->paste or ctrl-V?
> Why should middle click paste behave differently than edit->paste or ctrl-V?

Because they're completely different operations -- they have different behavior in terms of what text they paste and when the "selection" is cleared.  Middle click is just like the drop part of a drag-and-drop operation (with the "select" step being the "drag start"), not at all like a clipboard paste operation.

The very fact that middle click does anything but paste in the currently-selected text when some text is selected is a bug.
bz in comment #14:
> > Why should middle click paste behave differently than edit->paste or ctrl-V?
> 
> Because they're completely different operations -- they have different behavior
> in terms of what text they paste and when the "selection" is cleared.  Middle
> click is just like the drop part of a drag-and-drop operation (with the
> "select" step being the "drag start"), not at all like a clipboard paste
> operation.

so, this is WONTFIX?
Assignee: mozeditor → nobody
QA Contact: bugzilla
QA Contact: editor
Happens very often, that I try to middle mouse paste an URL in the selected location bar. I can't get used to the fact that this doesn't remove the selection although it has never worked.

Boris hit the nail on the head in comment 14, and although it pains me, I'm going to resolve the first bug I filed as INVALID.

->INVALID
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
Is there a way to create this kind of functionality? Either in terms of editing a file, creating a script, or making an extension? I've been looking for some way to do this and I think several people might like this functionality. Any starting points?
i do not  agree with boris in comment 14.

however if you do accept his view, when dragging and dropping text to the url or search bar, the previous contents of the bar is replaced.

boris claims that middle click emulates the drop. however whether the previous text is selected or not, the new text is inserted not replaced.

therefor the functionality would replace a selected text in the bar either way (if you assume middle click equals paste or if you assume middle click equals drop). the question would than remain whether to do a replace or insert in the case that the text is NOT selected (i would prefer the latter in this case)

please UNRESOLVE
> when dragging and dropping text to the url or search bar, the previous
> contents of the bar is replaced.

Only in Firefox (for example not in Seamonkey), and only for those textfields.  If you try dragging into another textfield, you will see that insertion happens, as expected.

I personally thing the URL bar behavior is whack, but that's a Firefox UI decision.  If they want, they can also make that happen for middle-click.  But editor by default should NOT be doing that.  And this bug is about what editor should do by default.  Note the product and component.
You need to log in before you can comment on or make changes to this bug.