[Xquartz-dev] Intermittent loss of input focus?

[Kyle J. McKay]

On March 22, 2015 01:28:33 PDT, Jeremy Huddleston Sequoia wrote:
>
> This has come up before.
>
> The issue is http://xquartz.macosforge.org/trac/ticket/58, and  
> there's a radar filed for the issue that is pretty much just as old.
>
> Note that XQuartz has no say in giving up focus.  Something else is  
> stealing focus from us.  I presume since it is just XQuartz that is  
> seeing this issue that there must be *something* I could do put  
> XQuartz in a mode that would prevent this focus loss, but I'm at a  
> loss to know what that is because I have no idea why the focus is  
> being allowed to be stolen in the first place.
>
> In any event, you can run the attached script (which Ken Thomases  
> provided to the list a couple years ago) to find out what is  
> stealing the focus and possibly stop it from periodically doing so  
> (by disabling it, deleting it, etc):
>
> <watch_activations.py>
>
> Hope that helps.
>
> --Jeremy

Just to satisfy my curiosity, I took a look at this.

I was able to duplicate it after building and running the "Mail Status  
Control.app" [1].

I think I understand what's happening.  Let me include some logging  
output:

004 17:35:56.744: 'appl'/7 (kEventClassApplication/ 
kEventAppFrontSwitched)
                   -psn_0_2757281 (X11.bin) pid 30108
                   "/Applications/Utilities/X11.app/Contents/MacOS/ 
X11.bin"
                   processMode=0x000012e0
004 17:36:55.880: 'appl'/7 (kEventClassApplication/ 
kEventAppFrontSwitched)
                   -psn_0_2937549 (System Events) pid 32342
                   "/System/Library/CoreServices/System Events.app/ 
Contents/MacOS/System Events"
                   processMode=0x000016e0 (modeOnlyBackground)

What's happening in this case is that 'Mail Status Control.app' is a  
LSUIElement=1 app and it periodically runs an AppleScript using this  
snippet:

appleScript = [[NSAppleScript alloc] initWithContentsOfURL: scriptURL  
error: &errorDict];
*ae = [appleScript executeAndReturnError:&errorDict];

Now the script in question includes a bunch of stuff in a 'tell  
application "Mail"' block (but it only runs that if Mail.app is  
already running, so if you try to duplicate this using "Mail Status  
Control.app" you will need to make sure Mail.app is already running).   
For whatever reason, that causes the front switch to "System  
Events.app".

Here's the thing though.  Other applications that are frontmost when  
the mail check triggers do not get a switch to System Events.

And, just like the bug report says, if I click on X11.app in the Dock  
to bring it back to the front it doesn't get them either.  However, if  
after clicking on X11.app in the Dock to bring it forward, I then  
click on a different X11.app window (other than the one that became  
active after clicking on X11.app in the Dock), X11.app will start  
getting the switch to System Events at the next mail check again.

So clearly, the code that activates a different X11.app window even  
when X11.app is already frontmost is enough to trigger the bug.

As a hack, X11.app could always examine the processMode  
modeOnlyBackground bit of the application that's becoming frontmost  
and attempt to compensate (looks like it's set for both LSUIElement=1  
and LSBackgroundOnly=1 apps).

-Kyle

[1] Downloaded source from archive.org and built it.
See <https://web.archive.org/web/20070818064601/http://xoomer.alice.it/czk/mac/ 
 >.