Re: master 4b98a79a50: Improve X event timestamp tracking

[Po Lu <luangruo@yahoo.com>]

Daniel Colascione <dancol@dancol.org> writes:

> If Emacs, in the background, calls x-focus-frame to activate a window
> and there's no explicit user intent to activate that window, the WM
> is within its rights to reject the proposed change to the window
> stacking. In this case, then the focus stealing mechanism is working
> at intended. Adding a "no, I really mean it" flag to x-focus-frame
> would encourage people to break this mechanism by passing that flag
> whenever x-focus-frame didn't work no matter the reason it didn't
> work --- even when this function *shouldn't* work because Emacs
> really is trying to do something that would trigger focus stealing
> prevent heuristics. 

Why would that be so?  The window manager doesn't get to decide what the
author of some Lisp code wanted.

Our users and developers are not sloppy programmers who write code that
steals focus from other windows for no reason whatsoever.  The intent is
demonstrated by code calling x-focus-frame being written.

> server.el is a special case: it's okay to break the usual event
> ordering here because the user *did* interact with Emacs, albeit
> through a side channel, not the X server. It's not that developers
> need to call two functions to make some API work, but rather,
> developers should call an additional function to communicate
> information to the core that allows an otherwise forbidden-by-design
> state transition to occur after all.

Why would the activation otherwise be "forbidden-by-design" (_our_
design, not the design of the window manager authors?)  Focus stealing
prevention doesn't exist on any other platform we support, so
x-focus-frame always works there.  As such, users expect the same from
X.  This is compounded by the fact that x-focus-frame says nothing about
requiring "user interaction" before the frame is activated.

> In other words, the clean abstraction *is* telling Emacs "Oh, by the
> way, the user interacted with this frame", not telling x-focus-frame
> "please, actually do your job for some reason". There's nothing X-
> specific about giving the Emacs core a hint that the user recently
> interacted with a frame in some manner not reflected in the normal
> flow of events. If most window systems want to ignore this hint,
> that's fine, but that doesn't make the hint a leaky abstraction.

It is a leaky abstraction because such a hint only exists on X, and was
never ever part of Emacs design.  Other window systems don't "ignore
this hint", because such a hint simply does not exist.

> Don't you think it is the job of server.el to tell that window system
> core code a fact that it wouldn't have otherwise known --- that the
> user interacted with the frame in some manner the window system
> wouldn't have otherwise know about?

No.  Lisp code not a platform implementation detail (be it in server.el
or whatever) does not have to know about this at all.

> I think an invocation of gnuserver that raiess a window ought to count
> as interaction. There are probably other use-cases as well.

No, it's not.  There is an actual startup notification protocol, but
it's not well suited for implementation in emacsclient.

> Yes. Ideally, we'd detect in emacsclient that emacsclient and emacs
> were running on the same X server and transmit the command buffer as
> a ClientEvent --- and we'd update our user timestamp when we got that
> event, giving us a globally correct event ordering. In the meantime,
> the "user interacted out of band" hint seems like the most
> conservative approach for working around focus stealing mitigations.

Client events don't include timestamps, so while you can ensure "correct
event ordering" with those, you cannot get the server time from them.

The actual protocol here is the startup notification protocol, which
emacsclient doesn't support for an obvious reason.