55312 - Paste (using middle button) of clipboard contents that come from a remote window fails

Status: RESOLVED FIXED

(Core :: XUL, defect, P5)

Description

[Boris Zbarsky [:bzbarsky]]

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

[Asa Dotzler [:asa]]

over to XPApps.

Comment 2

[Peter Trudelle]

->pavlov, cc pinkerton, ->future

Comment 3

[R.K.Aa.]

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

Comment 4

[R.K.Aa.]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

[sairuh (rarely reading bugmail)]

akkana, have you worked on this in the past?

Comment 8

[Akkana Peck]

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

Comment 9

[sairuh (rarely reading bugmail)]

would this be the same as bug 58333?

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Stuart Parmenter]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Stuart Parmenter]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

[Chris Siebenmann]

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

Comment 18

[Stuart Parmenter]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[R.K.Aa.]

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

Comment 21

[Deven Corzine]

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

[Mike Pinkerton (not reading bugmail)]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[R.K.Aa.]

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

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Stuart Parmenter]

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.

Comment 27

[Boris Zbarsky [:bzbarsky]]

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.

Comment 28

[Stuart Parmenter]

0.9.1

Comment 29

[Stuart Parmenter]

Attachment: change the number of attempts from 5 to 300

Comment 30

[Stuart Parmenter]

need r= and sr=

Comment 31

[Angela Butler]

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

Comment 32

[Boris Zbarsky [:bzbarsky]]

r=[e-mail]  This should make life a lot nicer....

Comment 33

[a-huntwork]

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

Comment 34

[Christopher Blizzard (:blizzard)]

sr=blizzard

Comment 35

[Peter Anvin]

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

[tor]

a=tor

Comment 37

[Stuart Parmenter]

checked in fix

Comment 38

[Boris Zbarsky [:bzbarsky]]

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

Comment 39

[Boris Zbarsky [:bzbarsky]]

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

Comment 40

[Boris Zbarsky [:bzbarsky]]

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

Comment 41

[Rickard Westman]

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

[Rickard Westman]

Attachment: Patch for cpu-speed-independent, non-cpu-hogging method

Comment 43

[Stuart Parmenter]

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

Comment 44

[Rickard Westman]

Sure, now filed as bug 87207.