Closed
Bug 87207
Opened 23 years ago
Closed 23 years ago
Paste of X11 selection (using middle button) occasionally fails
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
FIXED
mozilla0.9.6
People
(Reporter: rwestman, Assigned: bzbarsky)
References
Details
Attachments
(2 files)
2.29 KB,
patch
|
pavlov
:
review+
blizzard
:
superreview+
|
Details | Diff | Splinter Review |
115 bytes,
text/plain
|
Details |
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.
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
Reporter | ||
Comment 3•23 years ago
|
||
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))
Comment 4•23 years ago
|
||
reassigning to self
Assignee: trudelle → pavlov
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → mozilla0.9.3
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Updated•23 years ago
|
Keywords: mozilla0.9.3
Comment 6•23 years ago
|
||
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).
Comment 7•23 years ago
|
||
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Assignee | ||
Updated•23 years ago
|
Blocks: advocacybugs
Assignee | ||
Comment 8•23 years ago
|
||
Pavlov, could you review the patch?
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
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 13•23 years ago
|
||
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+
Assignee | ||
Comment 14•23 years ago
|
||
It's needed for PR_Sleep. Blizzard, does your review count as sr?
Assignee | ||
Comment 15•23 years ago
|
||
Blizzard says that he's good for sr. Taking this to check in (per conversation with pavlov)
Assignee: pavlov → bzbarsky
Status: ASSIGNED → NEW
Assignee | ||
Comment 16•23 years ago
|
||
Checked in. Rickard, thanks a ton for the patch!
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 17•22 years ago
|
||
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.
Assignee | ||
Comment 18•22 years ago
|
||
Likely bug 84973 is what you want.
You need to log in
before you can comment on or make changes to this bug.
Description
•