[Xquartz-dev] Xquartz-dev Digest, Vol 78, Issue 9

[René J.V. Bertin]

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.

Let's see how wide open the door is I'm about to kick in :)

I think that what happens is that some application starts in a way that it becomes the front application (is it (still) possible to launch an app through LaunchServices without that happening?). It, or the OS returns focus to the application that had it (which is something that could be done so quickly that there's very little chance anything gets lost). Normally, someone would know what window was the key window in that application, but X11 must be different. Either no window gets focus, or the wrong window.

Myself I've never seen this happening, and I spend a lot of time in XTerms. I wonder if the reason is that I never use QuartzWM but something more traditional (recently migrated from ctwm 3.5 to xfmw4 4.11.2). If that's the case though, my explanation above cannot hold, or at least I don't see how. I can't imagine that a legacy WM like ctwm is prepared to restore focus after the X11 server lost and regained focus, it's author likely never dreamt such a thing would even be possible :)

I *am* seeing another undesirable behaviour since updating from OS X 10.6.8 to 10.9 . I'm running rooted, and up to 10.6 I could bring 1 xterm to the front and have the others hidden behind native windows. Very practical if you're keeping a native browser window open for reference, for instance.
This is still possible, but periodically all X windows will pop to the foreground. The reverse also happens. It's as if certain events cause the application belonging to the key window to be brought to the foreground - and that could actually be the same event in which others lose their X11 input focus.

Hope this helps in some way...

R.

[Ken Thomases]

Post by René J.V. Bertin

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.

Let's see how wide open the door is I'm about to kick in :)
I think that what happens is that some application starts in a way that it becomes the front application (is it (still) possible to launch an app through LaunchServices without that happening?). It, or the OS returns focus to the application that had it (which is something that could be done so quickly that there's very little chance anything gets lost). Normally, someone would know what window was the key window in that application, but X11 must be different. Either no window gets focus, or the wrong window.

Well, there is something wrong in the way XQuartz is handling focus. It's actually possible to demonstrate it entirely within XQuartz. With an xterm window open and focused, simply open the Help menu in XQuartz's menu bar. Since the Search item in that menu has a text field that receives focus, it steals it from the xterm window. When you dismiss the menu, the xterm window does not get focus back. I suspect that the problem with external apps stealing focus is similar.

Something similar happens if you bring up the About XQuartz window and then close it. Or the Preferences window. Etc.

Basically, when a Cocoa window is focused, X11 is deactivated. When the Cocoa window is closed, X11 is not reactivated.

For the custom X server in CrossOver (based on a very old X.org code base), I created an invisible Cocoa window to act as a proxy for X11's focus. Basically, X11's focus has an entry in the Cocoa window list. When X11 has focus, that naturally takes focus away from other Cocoa windows. When Cocoa would return focus to its last key window (e.g. Help menu is dismissed; About panel is closed) and the proxy is that window, X11 gets focus.

Regards,
Ken

[Kyle J. McKay]

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
<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/

.