XEMBED: Preventing focus loops
otaylor at redhat.com
Thu Aug 21 16:07:32 EEST 2003
Currently, it's possible to get into loops with focus messages and
XEMBED. The problem occurs when you have a client that doesn't have
any internal focus locations, embedded into a toplevel without
any focus sites.
If we try to focus the first widget in the toplevel (say, when
the toplevel is mapped), we get the following sequence:
- Embedder sends XEMBED_FOCUS_IN/XEMBED_FOCUS_FIRST to the client
- Client finds no focus sites, sends XEMBED_FOCUS_NEXT to
- Embedder takes this as the user hitting Tab again, wraps
around to the beginning, and sends another XEMBED_FOCUS_IN
If you have nested embedding, then this can occur over two
My proposed solution to this is to define the currently unused data1
of the XEMBED_FOCUS_IN, XEMBED_FOCUS_PREV and XEMBED_FOCUS next
messages as a flags field, with currently one flag defined:
#define XEMBED_FOCUS_WRAPAROUND (1 << 0)
When sending one of these messages, the flag is set as follows:
- If the message is not generated as the result as one of
these three XEMBED messages, set the bit to zero
- When generating an XEMBED_FOCUS_IN in response to a
XEMBED_FOCUS_PREV or XEMBED_FOCUS_NEXT message and the
focus moved from the bottom of the window to the top
for a XEMBED_FOCUS_NEXT message or from the top of the
window to the bottom for a XEMBED_FOCUS_PREV message:
- If the bit was not set in the generating message, set
the bit in the new message
- If the bit was set in the generating message, a loop
has be detected. DO NOT SEND THE NEW MESSAGE.
- Otherwise, set the bit to the value found in the
All other bits in the field are unused and must be set to zero.
Notes about the proposal:
* The only difficult thing about implementing this proposal
is detecting when XEMBED_FOCUS_NEXT causes a wrap-around
at the toplevel. It required some hackiness to implement
in GTK+. I think most toolkits will be similar - a bit
hacky to do but possible.
* The two other approach that I considered were:
* assign a unique ID to the focus sequence so that an
individual embedder could check if it was repeating
a focus sequence.
Assigning a sufficiently unique ID is hard and requires
using all the remaining free space in the messages
instead of just one bit.You have to keep a history since
it is possible to have multiple interleaved infinite
* Some sort of response message to XEMBED_FOCUS_IN,
to allow tracking focus sequences without needing
a globally unique ID for the sequence.
This has the same problem with multiple interleaved focus
sequences as the prior solution and would also require
a lot of complicated bookkeeping to implement.
* I didn't up the protocol version because it is a highly
compatible addition - there is nothing you would do
differently if you knew that the other side didn't
Thanks for any feedback; if I don't hear anything in the next
few days I'll go ahead and make the changes to the spec.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8289 bytes
Desc: Diff to the XEMBED spec
Url : http://lists.freedesktop.org/archives/xdg/attachments/20030821/67905365/attachment.bin
More information about the xdg