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)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: bzbarsky, Assigned: pavlov)

References

Details

(Whiteboard: r=bzbarsky@mit.edu, need sr= and a=)

Attachments

(2 files)

change the number of attempts from 5 to 300
531 bytes, patch
Details | Diff | Splinter Review
Patch for cpu-speed-independent, non-cpu-hogging method
2.29 KB, 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.
over to XPApps.
Assignee: asa → trudelle
Component: Browser-General → XP Toolkit/Widgets
QA Contact: doronr → jrgm
->pavlov, cc pinkerton, ->future
Assignee: trudelle → pavlov
Target Milestone: --- → 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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....
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9
*** 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.)
Keywords: nsCatFood
*** 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
Target Milestone: mozilla0.9 → mozilla0.9.1
Priority: P3 → P5
need r= and sr=
Keywords: patch
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
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.
Whiteboard: r=r=bzbarsky@mit.edu, need sr= and a=
Whiteboard: r=r=bzbarsky@mit.edu, need sr= and a= → r=bzbarsky@mit.edu, need sr= and a=
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
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.
Blocks: 124140
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: