Re: [g-a-devel] Focus - AT vs. mouse/keyboard manipulation

["Elijah Newren" <newren gmail com>]

On 8/17/06, Bill Haneman <Bill Haneman sun com> wrote:
> On Wed, 2006-08-16 at 19:45, Elijah Newren wrote:
> ...
>
> Hi Elijah:
>
> I appreciate the underlying logic behind the focus-stealing prevention,
> and in particular the oft-cited case where focus moves out of a password
> field during authentication.
>
> It does however cause some serious problems for AT-SPI.
>
> We basically cannot transfer timestamps with our doAction requests,
> API/ABI-compatibly.

Ouch.  That doesn't sound good.

> The best we can do, I think, is have the ATK implementation code (in
> libgail) call gdk_x11_window_set_user_time() on the relevant toplevel.
> However, we have to get an appropriate timestamp from somewhere, and
> unfortunately it cannot be gotten from AT-SPI.  So libgail has to
> somehow obtain a timestamp for "the current time" when A(TK receives the
> request. Unfortunately the canonical CURRENT_TIME macro in X11 is just
> '0' which fails to solve the problem, I think.

Yes, that's correct.  GDK_CURRENT_TIME/CurrentTime (gdk & X names for
the same thing) are not useful in cases like this.

Bit of trivia: In fact, since 0 is the only known invalid timestamp,
the spec makes use of this to say that it should be treated as a
specialized "please do not focus me at all" hint.  So, this is quite
the opposite of what you want.

Short rant: CurrentTime is also buggy in a wide range of other cases
(even when the timestamp is meant for a message to the Xserver instead
of to the WM), as its use leads to subtle and nasty race conditions.
I'd be willing to guess that most uses of it are wrong in
application/toolkit/window manager codes.

> Would the value returned from gdk_x11_get_user_time() do the trick?

Short answer: No, it would result in no change whatsoever from the
current behavior, since this is precisely what gtk+ already does.

Long (explanatory) answer: gdk_x11_get_user_time() merely returns
display_x11->user_time, which stores the last time gtk+ was able to
detect that the user interacted with that particular process.
gdk_x11_window_set_user_time() exists to allow app authors to update
the timestamp on a window when there's some kind of special user
interaction with an application that gtk+ has no way of being aware
of.  (Examples of "special interaction": single-instance applications
forwarding requests to other instances to open a window, metacity
handling a keybinding and forwarding it to the gnome-panel to have it
show a "Run application" dialog, and apparently AT-SPI/ATK...).
gdk_x11_window_set_user_time() happens to also update
display_x11->user_time as a side effect.

To fix this:

We need some way of getting the timestamp from the sender process to
metacity.  You actually don't need to request the application author
to supply it; you could just call gdk_x11_display_get_user_time().
But we do need to either get it sent to the other process, or get it
sent to the WM in some manner that also lets the WM know precisely
which window (or windows) it will be appilcable for.  The latter is
pretty problematic.  It means we need to extend the spec so things
will work with other window managers as well (e.g. KWin).  But there's
an even bigger question of whether the latter option is even feasible;
does the sending process really know which windows will be launched in
response to an action?

We may need to dream up some creative ways of trying to get the
timestamp from the sender to the receiver inside AT-SPI (e.g. set a
property on certain windows saying they can receive additional or
modified messages, and have AT-SPI detect such, and then have AT-SPI
send additional or modified messages)


Hope that helps,
Elijah