XEMBED: Preventing focus loops

[Mike Hearn]

Is this change relevant for tray area users? There are no focus sites in
a tray icon as far as I know, but I'm not sure about the tray applet.

thanks -mike

On Thu, 2003-08-21 at 14:07, Owen Taylor wrote:
> 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
>    the embedder
>  - 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
> levels.
> 
> 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 
>    generating message.
>    
> 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 
>      focus loops.
> 
>    * 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
>    understand XEMBED_FOCUS_WRAPAROUND.
> 
> 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.
> 
> Regards,
> 						Owen
>