[15844] in Athena Bugs
Xt: XtGetSelectionValue can't deal with target type TEXT
daemon@ATHENA.MIT.EDU (Mike Barker)
Thu Mar 12 16:16:45 1998
To: bugs@MIT.EDU
Cc: testers@MIT.EDU
Date: Thu, 12 Mar 1998 16:16:26 EST
From: Mike Barker <mbarker@MIT.EDU>
re: Bad interaction of cut/paste between EZ and NEtscape on IRIX 6.3
Date: Wed, 14 Jan 1998 18:31:41 -0500 (EST)
From: Bill Cattey <wdc@MIT.EDU>
To: testers@MIT.EDU
Subject: Bad interaction of cut/paste between EZ and NEtscape on IRIX 6.3.
Repeat-by:
Start netscape
Start EZ
Enter a test string into ez text buffer
Click on OPEN button in netscape, and clear the old URL
highlight the test text in ez
paste it into the OPEN dialog box by pressing middle mouse button.
WAIT 30 seconds and the text will appear.
----
If you, instead, paste to Xterm the paste is immediate.
If you, cut from Xterm, the paste to netscape is immediate.
-wdc
for the record...
------- Forwarded Message
Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po8.MIT.EDU (5.61/4.7) id AA21951; Thu, 12 Mar 98 10:15:56 EST
Received: from PEMAQUID.MIT.EDU by MIT.EDU with SMTP
id AA24069; Thu, 12 Mar 98 10:16:17 EST
Received: by pemaquid.MIT.EDU (940816.SGI.8.6.9/4.7) id KAA23295; Thu, 12 Mar 1998 10:15:46 -0500
Date: Thu, 12 Mar 1998 10:15:46 -0500
Message-Id: <199803121515.KAA23295@pemaquid.MIT.EDU>
From: tb@MIT.EDU (Thomas Bushnell, n/BSG)
To: xbugs@x.org
Cc: alexp@MIT.EDU, mbarker@MIT.EDU, wdc@MIT.EDU
Subject: Xt: XtGetSelectionValue can't deal with target type TEXT
X-Name-Change: My name used to be `Michael'; now it is `Thomas'.
X-Tom-Swiftie:
"On the other hand, eating at a table is more civilized," Tom
countered.
VERSION:
R6.3, public-patch-2
CLIENT MACHINE and OPERATING SYSTEM:
SGI Irix on various SGI hardware
Solaris on Sparc
NetBSD on x86
DISPLAY TYPE:
irrelevant
WINDOW MANAGER:
Seen under twm, mwm, and others.
COMPILER:
gcc, I think.
AREA:
Xt
SYNOPSIS:
When an Xt-using program calls XtGetSelectionValue with the TARGET
parm set to the atom "TEXT" it ignores valid replies and ultimately
times out.
DESCRIPTION:
When an Xt-using program calls XtGetSelectionValue with the TARGET
part set to the atom "TEXT" Xt does the wrong thing.
According to the ICCCM, the correct response to a request for
conversion to type TEXT is never TEXT, but is instead some type chosen
by the selection owner:
The atom TEXT is a polymorphic target.
Requesting conversion into TEXT will convert into whatever encoding
is convenient for the owner.
The encoding chosen will be indicated by the type of the property returned.
TEXT is not defined as a type;
it will never be the returned type from a selection conversion request.
So a successful and valid SelectionEvent return to a request for TEXT
will have the target member set to something other than "TEXT"--for
example, "STRING".
lib/Xt/Selection.c uses the macro MATCH_SELECT to decide if a
SelectionEvent corresponds to a previous XConvertSelection request.
Tha macro (at the end of lib/Xt/SelectionI.h) reads:
#define MATCH_SELECT(event, info) ((event->time == info->time) && \
(event->requestor == XtWindow(info->widget)) && \
(event->selection == info->ctx->selection) && \
(event->target == *info->target))
Note that it does no checking for the case where *info->target is TEXT
but event->target is STRING. This is a valid reply, but it is
excluded by MATCH_SELECT. In fact, since it is never right to have
event->target be TEXT in a successful conversion attempt (see the
ICCCM except above) Xt is unable to deal with such requests at all.
REPEAT BY:
To repeat this you need a selection owner which understands TEXT
requests and responds in accord with the ICCCM. Most selection-owning
programs do not understand TEXT requests, but it happens that Andrew
Toolkit programs do. So fire up ez, or some other andrew toolkit
program, and select text in it.
The selection requester needs to be an Xt-using program which asks
for TEXT conversions. Again, most selection-requesting programs don't
do that. But it happens that the Motif library (which builds on Xt,
of course) does. So fire up a Motif program. We've tried both
netscape and willow.
So having cut from the atk program, and pasted into the Motif program,
you will notice a delay (generally five seconds) before the selection
appears. This is the principal symptom of the bug.
If you run xscope and watch the traffic between the two clients, you
will see that the Motif client requests a TEXT conversion, the atk
client responds (correctly) with a successful STRING conversion type,
and the motif client ignores it, quietly blinking it's cursor, until a
timeout expires; at that point the motif librapy issues another
request, this time for STRING, which succeeds happily.
------- End of Forwarded Message
