7787 - Selection doesn't copy text automatically

Status: RESOLVED FIXED

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

Description

[d.cary]

I'm running Red Hat 6.0 with the Enlightenment window manager (the default).
I downloaded the "latest release" version of Mozilla 1999 Jun 4.

In most applications, I can click-and-drag to select snippets of text,
then click (with my middle mouse button) to paste a copy into another application's window.
(The cool thing about this is that it's done entirely with the mouse -- when I use other operating systems, I have to, in addition, hit control-c and control-v to get the same net effect).

Mozilla works great when I do any of these things:
 * select text from Mozilla URI box, middle-click it into Nedit
 * clear Mozilla URI box, select text from Nedit, middle-click it into Mozilla URI box, then hit enter to load that URI
 * select text from a "text box" on a web page, middle-click it into Nedit
 * select text in Nedit, middle-click it into a "text box" on a web page.

There's only one situation where Mozilla fails me:
 * When I click-and-drag the main text of any web page, I see that it is selected. But then when I then middle-click into Nedit, nothing happens.
 * When I do "view source", I can select text. But then when I then middle-click into Nedit, nothing happens.

I notice that when I highlight something, if it turns black, I can't copy it. If it turns blue, I can copy it. When I highlight something that turns blue, and then highlight something that turns black, and then middle-click into Nedit, the text that is still selected blue gets pasted into Nedit.

By the way -- I really like the pretty colors on the HTML tags in the "view source" window.

Comment 1

[Akkana Peck]

(Rick, I hope you don't mind if I do a little triage here ...  it isn't really
your bug.)

This isn't a problem with middle mouse clicks in mozilla, since the middle mouse
clicks that don't work are happening in nedit.

The problem here is that you're expecting that selecting text automatically does
a "copy" (i.e. makes it available for pasting).  This is a perfectly reasonable
expectation for a Unix user, but it's not currently what we're doing, because
currently we're using the windows/mac model where you have to do an explicit
copy before you can paste.  Changing summary accordingly.

Mcafee and I have talked about this, and I have a bunch of comments in
widget/src/gtk/nsClipboard.cpp about how this needs to be done but is hard and
so isn't done yet (we need to make the clipboard a selection listener or
something, and we also need to deal with the fact that X users expect this while
Windows and Mac users don't yet the selection code is cross platform).  In the
meantime, you'll have to do an Edit->Copy after you drag-select in order to make
the nsClipboard aware of the selection, and then you should be able to paste
into other applications.  This should work in the browser, editor, and view
source windows (in the editor window you can also use ctrl-C to copy; eventually
that will be available in the other windows too).

I'm removing 5380 from "bugs depending on 7787" because it doesn't.  If this bug
mentioned middle-mouse pasting into the mozilla editor (which is what 5380 is)
then this bug would depend on 5380, but since you don't mention that I won't add
it to "bugs that 7787 depends on".  Incidentally, the bug that 5380 depends on
just got fixed, so I'm working on completing middle mouse paste into the mozilla
editor right now and expect to check it in today (yay!)

Comment 2

[Chris McAfee]

M8

Comment 3

[leger]

Per a request from Selection and Search component eng (mjudge) and qa (elig),
moving all "Selection and Search" bugs to new "Selection" component.  Original
"Selection and Search" component will be retired.

Comment 4

[Eli Goldberg]

[QA Assigning to self.]

Comment 5

[don]

Move to M11.

Chris, why do you have this bug?

Comment 6

[Chris McAfee]

Don, I have this bug because I was helping pink work with the Transferable
class, and this is a more-general problem than just an editor problem.
m12.

Comment 7

[don]

Is this related to bug #14026?

Comment 8

[Akkana Peck]

No, this is completely different from 14026.  That bug is on copy/paste commands
and menu items not being implemented in the browser window; this one is on
selection automatically doing a copy.

Shaver has been working on making this happen, and has been talking with mjudge
about the best way to add the necessary code into nsRangeList.  Cc'ing.

Comment 9

[Chris McAfee]

shaver.

Comment 10

[Mike Shaver (:shaver emeritus)]

dude.

(Reworking nsRangeList stuff now to appease mjudge, should have something
tonight.)

Comment 11

[chris hofmann]

is this close for m12?

Comment 12

[Mike Shaver (:shaver emeritus)]

It's going to get the airborne-hacking treatment, which means maybe Thursday
afternoon.

Comment 13

[Mike Pinkerton (not reading bugmail)]

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

Comment 14

[Mike Shaver (:shaver emeritus)]

shaver deftly dodges the oncoming M12 train.  He will catch his breath and leap
aboard the M13 one as soon as it starts boarding.

Comment 15

[Dan Erikson]

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

Comment 16

[Dan Erikson]

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

Comment 17

[Mike Shaver (:shaver emeritus)]

There's a lot of infrastructure that has to happen here, if we want to avoid The
Evil Static Accessor in nsRangeList.  I'd love it in M14, but someone might have
to take the patches from me and fix up the global notification system.

Sorry, guys. =/

Comment 18

[Stuart Parmenter]

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

Comment 19

[Dan Erikson]

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

Comment 20

[Doron Rosenberg (IBM)]

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

Comment 21

[Doron Rosenberg (IBM)]

very similar - bug 26168, but on MacOS.

Comment 22

[Richard Zach]

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

Comment 23

[Richard Zach]

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

Comment 24

[Akkana Peck]

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

Comment 25

[Eli Goldberg]

Nominating for beta2; high frequency of bug reports on this issue implies that
this is a common complaint.

Comment 26

[Chris McAfee]

shaver, can you post your patch here so we can give you
help and/or take this bug over?

Comment 27

[Mike Shaver (:shaver emeritus)]

Attachment: Patch to provide global-selection notification facility.

Comment 28

[Mike Shaver (:shaver emeritus)]

Don't touch that first patch!  It's the older one.

Putting the newer one up now.

Comment 29

[Mike Shaver (:shaver emeritus)]

Attachment: Better patch to create global-selection-notification facility.

Comment 30

[Mike Shaver (:shaver emeritus)]

Attachment: Patch to perform autocopy on selection change.

Comment 31

[Mike Shaver (:shaver emeritus)]

So.

The first-after-the-one-that-shouldn't-be-there patch (6759) should either be
applied or reworked to keep mjudge happy.

The second should be massaged into something that can live outside
widget/src/gtk (extensions/autocopy?) and have the pref issues fixed.

I might get to this, but not before the party.

Comment 32

[mjudge]

I am changing my code in selection to not send out spurious selection changes on 
mouse moves that do not affect selection. that should simplify your code. AND it 
will get rid of the static variables. i will do this next week. Sorry for the 
delay I actually thought i fixed that allready. Let me take this bug now and I 
will reassign it to you when I have fixed my nsSelection.cpp changes.

Comment 33

[mjudge]

have fix in my tree to get rid of the redundant selection notifications. This
will allow us to apply shavers patch without the static variables. i will check
in when m16 opens

Comment 34

[mjudge]

still some work to do for pinkerton and the copy team. but my part is done here 
i think

Comment 35

[gabriel]

Linux build 2000050608 - this is working perfectly. Why hasn't it been verified
yet ?

Comment 36

[Eli Goldberg]

Err...Because it's marked as P3/Normal, I have ~50 bugs to verify, and am going 
out on a 6 week disability leave for wrist problems in a few hours? ;)

But, seriously, if you'd like to verify this bug and confirm that it's in fact 
correctly implemented, go for it! You just need to:

- review every bug marked as a duplicate of this bug, and personally verify any 
that are different enough to warrant it
- be sure to explain _how_ you verify it, so that anyone CC'd can identify test 
omissions.

Comment 37

[gabriel]

Eli, I wasn't implying you weren't doing your job properly, I just thought it
might have been overlooked ;-) Sorry to hear about the wrist problems.

Verified: 21295 (followed instructions in that bug).
Verified: 19157 (selected text and pasted into terminal window using middle
button).
Verified: 23561 (ditto)
Verified: 21994 (selected text could be pasted into xemacs using the paste menu
option in xemacs).
Verified: 25593 (as per 19157)
Partially verified: 26168 (view source, select text, paste into xterm with
middle mouse) - needs verification under MacOS
Verified: 30542 (as per 19157)
Verified: 32077 (ditto)

Build version: linux 2000051808.


Hope this helps.

Comment 38

[Blake Ross]

*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
[e-mail] to [e-mail].  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...

Comment 39

[gabriel]

This one should be marked verfied. Eli and I have tested every case between us.