149079 - Mouse shortcut for copy doesn't work correctly

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect)

Description

[Sebastian Wittmeier]

When I want to copy some text with the mouse shortcut, Mozilla pastes the text
instead (entry fields) or does nothing (static text).

Normal behaviour would be:
Copy: Mark some text with left mouse button, press right button before releasing
left one
Paste: press right button, and before releasing it, press left button on insert
position

Comment 1

[Mike Kaply [:mkaply]]

I can't make copy work, but I can make the paste motion not execute a copy.

Comment 2

[Sebastian Wittmeier]

It was the other way round. Mozilla always did a paste.
It looks like their is only one handler for pressing both mouse buttons. Can it
be changed to always copy?

Comment 3

[Mike Kaply [:mkaply]]

I can't make it copy at all.

The code currently turns WM_CHORD into a mousebutton3 which in the Mozilla 
world is a paste.

So what is happening is that any chord (regardless of which button happens 
first) executes a paste.

The ONLY function I can have a chord map to is paste. There is no programmatic 
way to tell Mozilla to do a copy.

So my solution to this problem would be to prevent the copy chord from executing 
a paste which it does today.

Comment 4

[Sebastian Wittmeier]

Just read through some similar bugs in Bugzilla. The Unix people need a similar
feature with primary selections and X cut buffers. Perhaps that could be enabled
as a workaround.

Comment 5

[Sebastian Wittmeier]

Attachment: suggested changes for contentAreaClick.js

I've downloaded the source code.
I hope the attached changes would be a approach to solve the problem.

Comment 6

[Mike Kaply [:mkaply]]

Did you test the fix?

You can do this yourself.

Find the proper file in one of the .jar files in chrome directory.

Unzip the .jar. Modify the file. Rezip the jar.

You can test immediately.

Comment 7

[Sebastian Wittmeier]

Attachment: new patch (working)

nice, and a javascript console for testing

the first version did not work (of course *g*)
until now only static text gets copied

(I can't obsolete the previous attachment, also I created it)

Comment 8

[Sebastian Wittmeier]

Attachment: new patch (working)

nice, and a javascript console for testing

the first version did not work (of course *g*)
until now only static text gets copied

(I can't obsolete the previous attachment, although I created it)

Comment 9

[Sebastian Wittmeier]

Attachment: debugged patch as diff file

The patch only works with static text
For entry fields mozilla\editor\libeditor\text\nsEditorEventListeners.cpp has
to be edited.
Would you review the attached file so that it can be included in the official
distribution?

Sebastian

Comment 10

[Mike Kaply [:mkaply]]

The problem is that you have added functionality for everyone that should only 
be for Os/2 clients.

Unless this problem can be fixed in OS/2 specific files, it will never go out as 
part of the general Mozilla distribution.

Comment 11

[Sebastian Wittmeier]

Hi,
I don't think that feature has any disadvantages

How can I query the current operating system?
Or should that be solved by some new preference setting, that can be activated
only in the OS/2 prefs.js

Sebastian

Comment 12

[Mike Kaply [:mkaply]]

Attachment: OS/2 specific patch

I figured out how to make this happen in OS/2 specific code.

Comment 13

[Sebastian Wittmeier]

seems to work now (rev. 1.1).

Sebastian

Comment 14

[Mike Kaply [:mkaply]]

This only works in 1.1 - I haven't checked it in.

Alecf, do you have any idea on a better way to do this? It's pretty ugly.

Thanks

Comment 15

[Alec Flett]

the paste thing is pref-based, no? I would introduce a new value for the pref,
and then fix the XP code such that it honors this new value.... mainly I think
this patch is ugly because its using windowWatcher and its techincally sending
the wrong event..

Comment 16

[Mike Kaply [:mkaply]]

Detection for this mouse action doesn't exist at the XP level.

Basically for OS/2 cut and paste behavior, we need to know which mouse button
went down first and then we need to invoke copy/paste based on that.

This was the only way I found to tell Mozilla to do a copy or paste from widget.

Comment 17

[Sebastian Wittmeier]

>Basically for OS/2 cut and paste behavior, we need to know which mouse button
went down first and then we need to invoke copy/paste based on that.

To be exact that's not the real OS/2 behaviour.
OS/2 does a copy, when you are just selecting text and have not released the
left mouse button.
OS/2 does a paste in every other case.

OS/2 has only one WM_CHORD regardless which button was pressed first.

I hope an easier implementation gets possible now.

Sebastian

Comment 18

[Mike Kaply [:mkaply]]

That's not entirely correct.

There are two actions that paste - the WM_CHORD (pressing both mouse 
button simultaneously) as well as pressing the right and then the left 
(which is not technically a chord)

The copy action only happens if you select with the left mouse button 
and then press the right mouse button with the left button still held 
down.

Comment 19

[Mike Kaply [:mkaply]]

for my info after brade's changes land.

change these lines:
+ webShell = do_QueryInterface(docShell);
+ if (!webShell) {
+ break;
+ }
+ clipCmds = do_QueryInterface(webShell);
+ if (!clipCmds) {
+ break;to instead be something like this: 
nsCOMPTr<nsICommandManager> cmdmgr = do_GetInterface(docShell);
if (!cmdmgr) break;
cmdmgr->DoCommand("cmd_copy", nsnull);
or
cmdmgr->DoCommand("cmd_paste", nsnull);
depending when my api change lands, you may need to add another nsnull param
to the DoCommand calls

Comment 20

[Mike Kaply [:mkaply]]

Attachment: Good fix

I can't believe I never thought of doing this.

This is easy.

I emulate the NS_KEY events when I get the mouse actions. Done.

Comment 21

[Mike Kaply [:mkaply]]

Comment on attachment 114488 [details] [diff] [review]
Good fix

sr=blizzard (platform specific code)

This is OS/2 specific code, totally low risk.

I'd like this for 1.3 because this is a feature many OS/2 users have requested.

Comment 22

[Asa Dotzler [:asa]]

Comment on attachment 114488 [details] [diff] [review]
Good fix

a=asa (on behalf of drivers) for checkin to 1.3

Comment 23

[Mike Kaply [:mkaply]]

Fix checked in.