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.

over to XPApps.

->pavlov, cc pinkerton, ->future

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

Confing bug setting status new, based on dup. There is also related bug 51929.

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...

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....

akkana, have you worked on this in the past?

I see this too, and it doesn't require ssh; just a remote X window. Interesting bug.

would this be the same as bug 58333?

bug 58333 is a recent regression... This one has been around for awhile. Also, this bug is for remote windows _only_ -- local ones work fine. I've been using the proposed patches for bug 58333, and this bug still manifests itself...

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...

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).

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. :)

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....

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...

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.

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.)

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.

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....

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

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?

i plan to rewrite the clipboard to be async one day, so this will go away one day ;)

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

Is non-asynch clipboard the reason for bug 56219 as well? (Might as well dup it if so.)

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

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.

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.

0.9.1

need r= and sr=

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...

r=bzbarsky@mit.edu This should make life a lot nicer....

I guess everyone already knows this bug is pretty annoying, so this is just cc spam.

sr=blizzard

I find it puzzling that this bug is assigned as low priority as it is. It by and large makes the Mail editor unusable.

a=tor

checked in fix

filed bug 84973 to cover making the clipboard async, which is the real fix for this bug.

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

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

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.

hmm, riw: can you file a new bug and post this patch to it?

Sure, now filed as bug 87207.