Closed
Bug 55312
Opened 24 years ago
Closed 23 years ago
Paste (using middle button) of clipboard contents that come from a remote window fails
Categories
(Core :: XUL, defect, P5)
Tracking
()
RESOLVED
FIXED
mozilla0.9.2
People
(Reporter: bzbarsky, Assigned: pavlov)
References
Details
(Whiteboard: r=bzbarsky@mit.edu, need sr= and a=)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; m18) Gecko/20001004
BuildID: 2000100321 (and a few ones previous to it); M18
Trying to paste after copying from a remote window (forwarded over using SSH X
forwarding) does not work. This applies to trying to paste(using the middle
button) into form elements, URL bar, or window itself (as one would do with a
URL to open it). The strange thing is that for local windows this does not happen....
Reproducible: Always
Steps to Reproduce:
1. SSH to another machine
2. Open an emacs window that is X forwarded to your machine
3. Type some text in the window
4. Copy the text (highlight, or mark and M-w)
5a. Try to middle-click-paste into URL bar or form element
5b. Try to middle-click-paste into window itself
Actual Results:
5a. Nothing
5b. Mozilla prints:
****** returning null 2
->>>>>>>>>>>>>> Read Clipboard from memory
and does nothing else
Expected Results:
5a. Mozilla prints:
->>>>>>>>>>>>>> Write Clipboard to memory
->>>>>>>>>>>>>> Read Clipboard from memory
and pastes the selection into the URL bar or form element.
5b. Mozilla prints:
****** returning null 2
->>>>>>>>>>>>>> Write Clipboard to memory
->>>>>>>>>>>>>> Read Clipboard from memory
and opens the URL I just pasted in the window I pasted it to.
I've reproduced the problem with remote xterms, remote emacs windows.
I've also reproduced it with both XFree86 4.0.1 and XFree86 3.3.6
It was a very strange bug to see, since the X server should treat the clipboard
identically regardless of where the text was copied from....
It's not clear whether this is a Mozilla bug, and X bug, or an SSH bug... But
pasting to other local applications (emacs, xterm, gimp) from remote ones works
just fine. So this seems to be a Mozilla problem.
Comment 1•24 years ago
|
||
over to XPApps.
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
Comment 2•24 years ago
|
||
->pavlov, cc pinkerton, ->future
Assignee: trudelle → pavlov
Target Milestone: --- → Future
Confing bug setting status new, based on dup.
There is also related bug 51929.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 5•24 years ago
|
||
I've traced what happens with this bug a bit. The first place something seems
to go wrong is in widget/src/gtk/nsClipboard.cpp in function
GetNativeClipboardData. In particular, inside the loop that walks through and
tries to match the flavor being pasted there is the following conditional:
if ( currentFlavor ) {
nsXPIDLCString flavorStr;
currentFlavor->ToString ( getter_Copies(flavorStr) );
if (DoConvert(flavorStr, selectionAtom)) {
foundFlavor = nsCAutoString(flavorStr);
foundData = PR_TRUE;
break;
}
}
Now the outer if tests true at some point in the loop, but the inner if tests
false for that flavor. So foundData is left as PR_FALSE and the code that
actually places the clipboard data in the transferable is not executed.
This is all for copying from a remote window. Copying from a local window it
all works fine...
Reporter | ||
Comment 6•24 years ago
|
||
I think this is a timing bug. The X selection is fetched inside
nsClipboard::FindSelectionNotifyEvent() in widget/src/gtk/nsClipboard.cpp
This function has a retry loop which tries to get the clipboard contents 5 times
before giving up and timing out.
The problem is that the 5 repeats do not seem to give enough time to fetch
events from a non-local application. I've tried 20 repeats, and this bug
disappears. It also disappears if I compile with -DDEBUG_CLIPBOARD (probably
due to the time it takes to print a debugging statement in the retry loop) or if
I put a "usleep(30);" in the loop. None of these are good solutions (usleep is
not portable, more repeats may fail on a faster computer or slower net connection).
I'll try to think of a better solution, but I have done very little X
programming....
Comment 7•24 years ago
|
||
akkana, have you worked on this in the past?
Comment 8•24 years ago
|
||
I see this too, and it doesn't require ssh; just a remote X window. Interesting
bug.
Reporter | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
maybe the number of times that we sit waiting for data should be increased to
some larger number... it could make things act a bit slower, but would hopefully
the data would come in...
Reporter | ||
Comment 12•24 years ago
|
||
Two questions:
1) Why exactly do we limit the number of times we wait? Are there specific
conditions that could cause the X server never to return an answer there?
2) The code will never take more time than it takes for the data to come in,
right? If so, increasing the number of iterations will only possibly make
things slower in any failure cases that exist per question 1.
It seems to me that raising the number of iterations would work at least as a
temporary fix. I'm not sure what a safe number is to raise to... It would be
good to test this with a fast computer and applications being forwarded over
very a slow connection (modem or something along those lines).
Assignee | ||
Comment 13•24 years ago
|
||
nedit, in conjunction with lesstif causes X to never return any data (ugh), so
yes, the apps that take a long time are the only ones that are going to make
mozilla run slower, so raising the number is probably ok. I don't really have
any good suggestion on a number, however, 20 seems like a good number to me. :)
Reporter | ||
Comment 14•24 years ago
|
||
I'll try some numbers and see how many retries is seems to take on my system on
average. Then I guess we should at least double that....
Reporter | ||
Comment 15•24 years ago
|
||
Well, here's my data. At anything below 50 retries, I got no paste
functionality at all. Between 50 and about 400 retries (in increments of 25) I
got flaky paste functionality -- sometimes it would work, sometimes not.
At 400 or more retries it seems to work every time...
Reporter | ||
Comment 16•24 years ago
|
||
I should add that 400 retries on my machine takes at most a third of a second.
Usually more like a tenth.
Would it be worth trying to solve the never appearing data problem by setting an
alarm for a second and then breaking out of the loop on a SIGALRM? Would that
be sufficiently portable? It should be portable to all Unix systems, and this
_is_ gtk-specific code.
Comment 17•24 years ago
|
||
Speaking personally: this is a very frustrating and mysterious bug to
experience. I hope that some patch can be developed, especially since
other applications (eg xterm) seem to have no problems retrieving selections
in the same situation.
I suspect that this may need a small code rethink to make the retrieval
of selections somewhat asynchronous. I believe that this is the model that
xterm uses. (But likely this sort of a change is not going to be possible
in the near future.)
Assignee | ||
Comment 18•24 years ago
|
||
X's selection stuff is async.. the problem is is that mozilla's clipboard
interfaces aren't, so we have to block to get the data back from X...
Unfortunatly, there is a case when using nedit with lesstif that causes it to
never send a SelectionNotify event with or without data on it, so we can't sit
there forever.
Reporter | ||
Comment 19•24 years ago
|
||
Well, the problem with the current approach is that the time it takes for the
data to come in is more or less fixed for remote connections (more or less
corresponds to the latency on the connection, for small datasets), while the
amount of time that Mozilla waits is essentially determined by the speed of the
processor.
What would be a good way of making Mozilla wait for some constant amount of
time? Something on the order of 1 or 1.5 seconds, I would say....
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
Comment 20•24 years ago
|
||
*** Bug 64603 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
Adding a fixed delay would be a bit of a kludge. Could it be modified to work
properly with X11's async mechanisms through the use of a callback of some sort?
Comment 22•24 years ago
|
||
i plan to rewrite the clipboard to be async one day, so this will go away one day
;)
Reporter | ||
Comment 23•24 years ago
|
||
*** Bug 67193 has been marked as a duplicate of this bug. ***
Comment 24•24 years ago
|
||
Is non-asynch clipboard the reason for bug 56219 as well?
(Might as well dup it if so.)
Reporter | ||
Comment 25•24 years ago
|
||
*** Bug 73885 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 26•24 years ago
|
||
should we go and make the number like 300 or something? i'm ok with doing
that... otherwise, i'm going to move this to a later milestone than 0.9.
Reporter | ||
Comment 27•24 years ago
|
||
I would support making it 300 for now so it's not dogfood for quite so many
people. We should keep the bug open for the real fix, however.
Assignee | ||
Updated•24 years ago
|
Priority: P3 → P5
Assignee | ||
Comment 29•24 years ago
|
||
Comment 31•24 years ago
|
||
Per PDT Triage effort: changing the targeted milestone to "mozilla0.9.2".
Please feel free to renominate/address bug if time is available AFTER all
currently targeted 0.9.1 bugs are resolved.
.Angela...
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Reporter | ||
Comment 32•24 years ago
|
||
r=bzbarsky@mit.edu This should make life a lot nicer....
Comment 33•23 years ago
|
||
I guess everyone already knows this bug is pretty annoying, so this is just cc spam.
Assignee | ||
Updated•23 years ago
|
Whiteboard: r=r=bzbarsky@mit.edu, need sr= and a=
Assignee | ||
Updated•23 years ago
|
Whiteboard: r=r=bzbarsky@mit.edu, need sr= and a= → r=bzbarsky@mit.edu, need sr= and a=
Comment 34•23 years ago
|
||
sr=blizzard
Comment 35•23 years ago
|
||
I find it puzzling that this bug is assigned as low priority as it is. It by
and large makes the Mail editor unusable.
Comment 36•23 years ago
|
||
a=tor
Assignee | ||
Comment 37•23 years ago
|
||
checked in fix
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 38•23 years ago
|
||
filed bug 84973 to cover making the clipboard async, which is the real fix for
this bug.
Reporter | ||
Comment 39•23 years ago
|
||
*** Bug 85263 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 40•23 years ago
|
||
*** Bug 85594 has been marked as a duplicate of this bug. ***
Comment 41•23 years ago
|
||
I still see problems caused by this bug, even with the patch that increases the
number of iterations to 300. On my machine (which is not overly fast) 300
iterations corresponds to a timeout of 25 ms, during which Mozilla and the X
server competes for CPU with the application owning the selection. It appears
that this is not always enough for the applications I run (some of which use
garbage collection, which I think is the culprit in my case.) The success of
the current method not only depends on the speed of your CPU, but also on how
the OS schedules the involved processes (selection owner, Mozilla, X server.)
The solution I currently run (and which is working just fine) is in the attached
patch, which removes the ClipPing and replaces it with repeated non-blocking
checks of the event queue. Between every check, it sleeps for a little while
(20 ms) to give the selection owner time to respond and to be reasonably
system-friendly. It finally times out after 500 ms, which I think is fast
enough for the abnormal case where the selection owner doesn't respond at all,
and long enough for programs with occasionally sluggish event handling.
Of course, a proper async solution would be better, but I think this patch is a
more workable workaround than the current workaround.
Comment 42•23 years ago
|
||
Assignee | ||
Comment 43•23 years ago
|
||
hmm, riw: can you file a new bug and post this patch to it?
Comment 44•23 years ago
|
||
Sure, now filed as bug 87207.
You need to log in
before you can comment on or make changes to this bug.
Description
•