Emacs windows not appearing in AltTab list

[mjog]

Describe the bug

Emacs windows not appearing in AltTab list

Steps to reproduce the bug

1. Open an Emacs window
2. Press shortcut to invoke AltTab window
3. Notice Emacs window is not present

[lwouis]

Hi @mjog!

Could you please clarify which Emacs app you're running? It seems that mac ports are various, and exhibits issues. I see here for instance that there are flags specifically to get a version that has correct windows.

[mjog]

I can't currently reproduce this either, may be intermittent? I restarted AltTab yesterday.

[lwouis]

Could you still please share with emacs app/port/version you are using?

[mjog]

Sure thing, this one: https://vigou3.gitlab.io/emacs-modified-macos/

[dsedivec]

I think I can reproduce this:

1. Grab Emacs 27.1 from https://emacsformacosx.com
2. Run Emacs (I ran it from a shell a la /Volumes/Emacs/Emacs.app/Contents/MacOS/Emacs -Q because my Emacs config doesn't like multiple instances running; -Q tells Emacs not to load my config)
3. Type ⌥X set-var return ns-use-native-fullscreen return nil return
4. Type ⌥X toggle-frame-fullscreen return , which should make the window full screen but not in the standard macOS full screen way
5. Invoke AltTab

Expected result: You can see the Emacs window in the list of windows you can switch to

Observed result: You do not see the Emacs window, but instead only an icon which I think means something like "launch Emacs"

(I think it tried to start a brand new Emacs when I made the mistake of selecting it once.)

I am testing this on macOS 10.15.7, AltTab 6.17.0.

(You can type ^X^C to exit Emacs.)

I am guessing that some of the most important code for "non-native full screen" is here, looks like setting some kind of "full screen auxiliary window collection behavior". (Emacs users like me love this "non-native full screen" because you don't end up in a different Space™, you can have ordinary windows like terminals on top of Emacs's big window for code editing, etc.)

Edited to add: AltTab seems to work fine with Emacs when Emacs is not in full screen mode, or when Emacs uses the normal ("native") macOS full screen mode.

Thank you for AltTab. :)

[dsedivec]

Maybe you're interested to see what Accessibility Inspector has to say about the non-native full screen Emacs window? (Pardon the green veil added by Accessibility Inspector, I've just got the one screen.)

As you pointed out in the yabai issue you linked to above, the Emacs's windows seem to have role AXTextField This is true even when the Emacs window is not full screen. However, in non-native full screen, the normal Emacs window's subrole is AXUnknown. When that window is full screen, its subrole becomes AXStandardWindow, as you see above.

[lwouis]

@dsedivec thank you for the nice detailed information!

I think it's the classic case of the window not being a real window (AXUnknown), and AltTab not showing it. AltTab avoids showing non standard windows because if it did, you would have all sorts of mini UI elements, large invisible windows, etc, polluting your view. The best heuristic I found over the years to detect what a window is, to the end-user, is to use the accessibility attributes subrole and role. There is an open ticket flagged with Breakthrough needed, where hopefully one day someone will suggest a better way: #456

In the meanwhile, I have been hardcoding app-specific exceptions, after users reported issues with these apps.

The best of course, would be for the people behind emacs to use a window to do this non-native fullscreen window feature. Then it would simply work with AltTab. Have you opened a ticket with them?

[dsedivec]

The best of course, would be for the people behind emacs to use a window to do this non-native fullscreen window feature. Then it would simply work with AltTab. Have you opened a ticket with them?

Do you mean to just have them set the role to AXWindow? The patch to do that seems very simple. I'm trying to compile Emacs with it now. If it works out, I'll propose it upstream and see what they say.

If it works, I'm mostly mystified why they aren't already using it. My first guess would be that it somehow impairs accessibility, and to do something like properly enclose the text area in a normal window would be too invasive of a change. But I can ask.

[dsedivec]

Do you mean to just have them set the role to AXWindow? The patch to do that seems very simple. I'm trying to compile Emacs with it now. If it works out, I'll propose it upstream and see what they say.

I just rebuilt Emacs HEAD with the patch for AXWindow and AltTab still doesn't list it, despite the role now showing AXWindow in Accessibility Inspector. Is there something else that could be causing AltTab to ignore Emacs?

[lwouis]

I see on your screenshot Subrole: AXUnknown. AltTab only shows windows with subrole being either kAXStandardWindowSubrole or kAXDialogSubrole.

You can see the full logic to filter out windows from non-windows here. It's pretty simple.

Given the simplicity of the patch you shared, you may be able to do the same change to subrole. Something like:

if ([attribute isEqualToString: NSAccessibilitySubrole])
   return NSAccessibilityStandardWindowSubrole;

[dsedivec]

I see on your screenshot Subrole: AXUnknown. AltTab only shows windows with subrole being either kAXStandardWindowSubrole or kAXDialogSubrole. [...] Given the simplicity of the patch you shared, you may be able to do the same change to subrole. Something like:

And indeed thirty seconds of testing indicates that works. I used this patch against Emacs's native-comp branch and now I can see "full screen" Emacs windows in AltTab. I should probably suggest this upstream, or find out why Emacs doesn't already do this.

Thanks for your help!

[lwouis]

Cool! I'll close this ticket then. Feel free to report here if it gets fixed upstream 👍