45743 - Mozilla repeatedly reads clipboard when it has the selection

Status: RESOLVED INVALID

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

Description

[Matthew Cline]

When Mozilla acquires the selection, it constantly reads the contents of
the clipboard, until it looses the selection.

To reproduce:

1) Start up Mozilla in a terminal (on UNIX) so you can see the
   output when Mozilla reads or writes the clipboard.
2) Select any text in Mozilla.
3) The message "->>>>>>>>>>>>>> Read Clipboard from memory" keeps
   on repeating until Mozilla loses ownership of the clipboard.

Comment 1

[Matthew Cline]

Oh, environment info:

  Build 2000071714, Linux 2.2.14 i686, RedHat 6.1

Also, this only seems to hapen on the 20000717 build of KDE, so this
might be a problem with KDE and not with Mozilla.  Since it's unlikely
anyone else has this exact KDE build, I'll be willing to debug this
one, if someone else can point me at some likely places to look.

Comment 2

[Blake Ross]

I'm pretty sure this is a known bug, but sending to selection.

Comment 3

[mjudge]

akkana are we still copying to the clipboard on drag here? or only when someone 
pastes what we have??

Comment 4

[mjudge]

changing milestone

Comment 5

[Akkana Peck]

I've heard this problem reported from someone using SuSE 6.4 (I think), but
haven't ever seen it myself (on redhat 6.2).  I bet it's a system library
problem (kde or something else).  I'm glad to hear that we have someone who's
seeing it and is willing/capable of debugging it, though!

On redhat, when I select, I see
->>>>>>>>>>>>>> Write Clipboard to memory
but I don't se e
->>>>>>>>>>>>>> Read Clipboard from memory
until I paste somewhere.

So I'd break in the place where the "Read Clipboard" message is getting printed,
and see why that's getting called on select -- it shouldn't be called at all.

Cc'ing Pavlov (linux clipboard owner) and Pinkerton (general clipboard owner) as
they're more familiar with the current workings of the clipboard (what exactly
do those messages mean, and when should they be called?)

Comment 6

[a-huntwork]

I also see this on kde 1.92, i.e., kde 2 beta 3.  I'm using 2000072712, an m17
build.  My system is basic rh 6.2 other than the kde2 stuff

Comment 7

[a-huntwork]

The problem is the kde2 clipboard monitor klipper.  If you kill the process
called kdeinit:  klipper, this problem goes away.  But oh no, then kde2 won't
ask you if you want to do something really cool with evry url you highlight!
horrors!

Comment 8

[a-huntwork]

The code for klipper is here.  It's not much at all, and I almost understood it,
in spite of being less than highly experienced with c++.  Maybe someone with a
clue could tell what is going on here.

http://us.mandrakesoft.com/cgi-bin/cvsweb.cgi/kdebase/klipper/

Comment 9

[a-huntwork]

This is completely an effect of klipper.  Klipper sets up a timer, and when it
fires, klipper reads the clipboard.  Akkana says that this causes GetData to be
called, which is the normal and desired effect.  The only actual problem here is
that pinkerton is spamming us with his debugging output.  :)

KDE 2 betas will probably be widely used within the next several weeks.  They
are already much more stable than mozilla (:)) and currently in bugfix only
mode, so it seems unlikely to me that klipper will change substantially with
respect to this behavior.  So pinkerton's debugging output will be seen a LOT by
a whole bunch of people, who will undoubtedly consider it a bug in mozilla. 
About 12 dups of this bug will be opened in the next month.  So maybe it's time
to put #ifdef DEBUG_pinkerton around this. :)

Comment 10

[Stuart Parmenter]

we can always remove the printf, but that doesn't really help solve this
problem.  klipper constantly asking for data is going to be a large performance
hit.  we have to block a bit and do lots of X traffic when people request data
from us.  I seriously suggest you talk to KDE people, because klipper's behavior
sucks.

Comment 11

[a-huntwork]

Just submitted a "patch" or more like an idea with some code involved, to the
maintainer of klipper, [e-mail], and pointed him to this bug.  The bug
in klipper doesn't look like it's very hard to fix, as the qt library fires a
signal when the clipboard selection changes.  However, my specific fix may be
tainted by my inexperience with c++ and qt.  We'll see.

Comment 12

[a-huntwork]

This bug is dead.  Sometime in the next week, the kde 2 nightlies will contain
the fix which does not poll the clipboard, and therefore does not cause the
printf to fire.  I haven't the privileges to close this, but I think it should
be closed.  

Comment 13

[Mike Pinkerton (not reading bugmail)]

okies.

Comment 14

[Akkana Peck]

Yay!  Thanks very much, a-huntwork!

Comment 15

[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 16

[John Morrison]

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