Handle native tabs properly

[dominiklohmann]

Issue

NSDocument-based applications send window created notification on tab creation.

This is a re-iteration of the same issue with chunkwm (https://github.com/koekeishiya/chunkwm/issues/235).

I have created another radar for this issue now that the Catalina beta is a thing. This time around, I got an answer: Works as expected.

iPad apps brought to the Mac using Catalyst have the same behaviour, so this should probably be fixed before the release of macOS 10.15 Catalina.

Proposed fix

Investigate how Amethyst works around this and replicate the behaviour in yabai.

Here's what they're doing from my understanding: When a kAXWindowCreated notification triggers, check whether the window has the same position and same size as another window of the same application. For applications like Terminal, some tolerance is needed because the window size may change ever so slightly when changing tabs.

[koekeishiya]

I don't think the implementation in Amethyst is complete, or fully robust. How does Amethyst handle minimization and deminization of such grouped windows? What about hiding and restoring an application that has a grouped window, and a "normal" window?

I'm also unsure if the same heuristic applied by Amethyst can be used here, because I believe that Amethyst behaves differently in terms of how windows are stored / tracked. IIRC they have some caching mechanism that is flushed and regenerated upon a space activation? I may be mistaken as the last time I looked at Amethyst was maybe 4years ago.

[koekeishiya]

So I just tried Amethyst to see how it behaves with tabbed windows.

• Creating a new tab seems to work fine.
• Closing a tab is fine.
• Switching between tabs are ok.
• Minimize and deminimize seem to work fine.

Hiding an application did not work for me at all, regardless of the application having tabbed windows or not, so I could not verify my assumption there.

I did take a quick glance at the code that is run upon a space change, and it does indeed drop and regenerate some sort of cache of windows that it consider to be current. This is not something that can be replicated in yabai, as we don't have this form of caching. In yabai, a window is tracked from the moment we learn about its existence until it is destroyed, regardless of which space or display or whatever we transition from/to, or consider active.

I'll probably spend some time to observe the behaviour in detail myself, and if I can come up with some solution that can integrate properly with yabai, I will support this. If I cannot do so, I'd rather state that tab integration is not supported. Implementing a partially working, but flawed solution, would be worse than ignoring it completely in my opinion.

[koekeishiya]

There is an additional case here that Amethyst also does not seem to tackle at this moment in time.

When a window is de-tabbed we somehow need to detect this and tile the window.

[koekeishiya]

I spent a bit of time looking into this, and we can actually query information about the tabs using the accessibility API. That seems a lot better to me than having to try and differentiate based on which order we receive notifications in.

[koekeishiya]

Tested some more. The accessibility API is not reliable. All it really gives us is the fact that a tabgroup has been created, and the number of tabs. However, if you go from a non-tabbed window to a window with 3 or more tabs (spamming new tab hotkey). The creation of all but the last tab will not report as part of a tabgroup, as the tabgroup have yet to be created.

Looks like we may have to do some weird combination, or rely on notifications only, which I'm not sure will be good enough.

[koekeishiya]

When a window is de-tabbed we only receive moved and resized notifications for said window.
There is no consistent way to know when these events correspond to a window being de-tabbed, or the window group itself being moved around.

[dominiklohmann]

When a window is de-tabbed we only receive moved and resized notifications for said window.

So when a tab bar is present in an NSDocument-based app, there's an element with a role of AXTabGroup, which has tab count + 1 children (the tabs themselves and the create tab button). The actual tab buttons have the role AXRadioButton.

When a window is de-tabbed, this count changes. To associate this with the corresponding window id, there'd need to be a mapping of tab button UI element identifier (does such a thing exist?) to tab window id.

[koekeishiya]

When a window is de-tabbed, this count changes. To associate this with the corresponding window id, there'd need to be a mapping of tab button UI element identifier (does such a thing exist?) to tab window id.

The problem here is that the detabbed window no longer has that tab-group as an accessibility element, so we are not able to know which group it came from. Tracking windows that belong to a group is not possible, at least I have not managed to do it reliably:

Tested some more. The accessibility API is not reliable. All it really gives us is the fact that a tabgroup has been created, and the number of tabs. However, if you go from a non-tabbed window to a window with 3 or more tabs (spamming new tab hotkey). The creation of all but the last tab will not report as part of a tabgroup, as the tabgroup have yet to be created.

[dominiklohmann]

Couldn't you created a cache that maps window id -> tab group?

Now when a window is moved/resized, you check if the windows id belonged to a different tab group than it does now.