1. Open an xterm. This will be the "fast xterm".
2. Open a second xterm. This will be the "managing xterm".
3. In the managing, xterm, do
ssh -X localhost <return>
And log in as necessary. This will provide you with a shell
session with X environemtn variables arranging indirection through
the ssh running in the managing xterm.
4. In the remote shell in the managing xterm, type
xterm <return>
This generates a new xterm. This will be the "slow xterm".
5. In the slow xterm, select some text. Double clicking on some
bit of the prompt will do.
6. In the managing xterm, type
~ ^Z
This suspends the ssh session. The slow xterm becomes frozen -
avoid interacting with it.
7. In the fast xterm, press
Shift+Insert
and then type some text. You will see the text echoed immediately.
8. In the managing xterm, type
fg <return>
The slow xterm wakes up, and now the selected text will appear in
the fast xterm, out of order.
This procedure ought to work to test for this bug with any program
which can work over a forwarded X connection.
Note that for the but to occur, the "slow xterm" does not need to be a
terminal program at all. I often experience the bug (I did, in fact,
just this morning) with a web browser as the "slow" program.
Web browsers are often preoccupied with rendering kittens and leaking
memory, so c&p from a web browser into a shell often provides a
good opportunity for this mispaste race.
I think xterm should buffer the input until the selection arrives.
There should be a timeout which should be configurable.
If the timeout occurs, I guess the buffered input should be discarded
and the bell should be rung.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
