Closed Bug 87207 Opened 23 years ago Closed 23 years ago

Paste of X11 selection (using middle button) occasionally fails

Categories

(Core :: XUL, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla0.9.6

People

(Reporter: rwestman, Assigned: bzbarsky)

References

Details

Attachments

(2 files)

Pasting text using the middle mouse button fails if the owner of the X11
selection (containing the text to be pasted) takes too much time to respond to
the query from Mozilla.  The timeout currently depends on the speed of your
computer.  On my PC (K6-III+/450), the selection owner has to respond within 25
ms, which is not always generous enough.  In real life, I see this with
sekection owners using garbage collection, where a gc delay of a few 100 ms is
not unusual.

The wait is currently implemented by a retry loop which loops 300 times, and
communicates with the X server for each iteration.  This keeps three processes
running during the wait: the selection owner, Mozilla, and the X server.  Since
the selection owner has to compete with the other processes for CPU, the timeout
period depends not only on the speed of the computer but also of the scheduling
within the OS.  Therefore, changing the number 300 to a larger number would not
be a very good way to achieve a more generous timeout, since the proper value
would be different for different computers and operating systems.

The attached patch replaces the current waiting method with one where the
timeout is practically independent of the CPU speed and OS scheduling, and which
does not compete with the the selection owner for the CPU.  It uses 500 ms as
the timeout, which I think is fast enough in the abnormal case where the
selection owner doesn't respond at all, but is generous enough to give even
sluggish programs ample time to respond. 

The patch was originally proposed as a better way to deal with bug 55312 (now
closed) but it was suggested that I filed a fresh bug and included the patch
with it.  In the discussion of bug 55312 it was hinted that an asynchronous
solution to this problem may be implemented some day, which is a cleaner (but
more involved) solution.
The second attachment is a small Tcl/Tk script which can be useful for testing
purposes.  It implements a selection owner which takes 200 ms to respond to a
query.  Using this, I have verified that pasting the selection fails with
Mozilla build 2001061706, while it works fine using the patch in question
(applied to a Mozilla build from the current version in CVS (21-Jun-2001))
reassigning to self
Assignee: trudelle → pavlov
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla0.9.3
Status: NEW → ASSIGNED
Keywords: nsCatFood, patch, review
Keywords: mozilla0.9.3
-> 0.9.4 per Pavlov
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Also seen on mozilla 0.9.3 with linux 2.2.19.
Moz is running locally and I was trying to paste a selection made on client
connecting remotely (via SSH X tunnel).
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Blocks: advocacybugs
Pavlov, could you review the patch?
I'm still seeing this with moz 0.9.4. I've forwarded a connection over 2 ssh's
(to get past a firewall), and XEmacs (forwarded) usually can't answer with the
current  solution. If I hit the middle button like crazy (10 times or so) the
paste finally makes it.
I went through the trouble of fetching the source via CVS and applying the patch
by riw (id 39600), and pasting seems to work a-ok, with the slow connection over
which it doesn't work with mozilla-0.9.4. I know it is a hack, but works a hell
of a lot better than in the "official" release.
.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Comment on attachment 39600 [details] [diff] [review]
Patch for cpu-speed-independent, non-cpu-hogging approach

r=blizzard Messy, as this code usually is but acceptable.
Attachment #39600 - Flags: superreview+
Comment on attachment 39600 [details] [diff] [review]
Patch for cpu-speed-independent, non-cpu-hogging approach

r=pavlov.

why do we need to #include "ptthread.h" ?  can that be removed?
Attachment #39600 - Flags: review+
It's needed for PR_Sleep.

Blizzard, does your review count as sr?
Blizzard says that he's good for sr. Taking this to check in (per conversation
with pavlov)
Assignee: pavlov → bzbarsky
Status: ASSIGNED → NEW
Checked in.  Rickard, thanks a ton for the patch!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
I'm still seeing this bug, or something similar on my work machine (Dual 450 PII)

Middle-button paste freezes the system and usually doesn't work (even from local
apps).

Should this bug be re-opened or is there another one out there to cover what I'm
seeing.
Blocks: 124140
Likely bug 84973 is what you want.
Blocks: 223705
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: