Opening new tabs in Terminal changes its position in the layout

[ianyh]

System

• Amethyst version: 0.11.4b
• macOS version: 10.13 Beta

What's the problem?

When in tall layout I had a terminal window with 2 tabs in a layout with 3 windows. It was in the first position in the secondary pane, but when adding a new tab it moved to the second position in the secondary pane.

How can it be reproduced?

What applications are involved?

Has anything fixed it, even temporarily?

dotfile (if you have one)

{

}

Screenshots

Trello Card

[ianyh]

This appears to actually be a pretty big issue with tabbed windows (at least in Terminal). The tabs switch between windows, but they are windows with different window ids. They appear to be fully fledged windows. Their parents are the application. Not sure how to get past this one.

[ianyh]

At the very least this isn't a regression (it happens in 0.11.3).

[koekeishiya]

From what I've seen, tabbed windows are also reported through the accessibility notifications.
https://github.com/koekeishiya/chunkwm/issues/80#issuecomment-309263422

An ugly workaround is to rebalance (reflow in amethyst?) the window representation after a window created / destroyed event. Interested to hear if you come up with a better solution.

[dominiklohmann]

What applications are involved?

This happens to all windows that use native Cocoa tabs that were introduced in macOS 10.12 Sierra. If you use the "Show All Tabs" option it somehow resets.

Safari is not affected, its tabs are not the Cocoa defaults for whatever reason.

[selfawaresoup]

Did some testing on this (on macOS 10.13.2):

• Finder is also not affected.
• Terminal still is affected as described above.
• Preview behaves weird in a different way: When I open a second document and "Merge all windows", an empty space remains for each window that just disappeared. As soon as I close even just one tab, things return to normal.

[ianfixes]

OSX 10.13.6 (17G65):

Opening a new tab, or switching tabs within terminal causes the "empty space" issue. Minimizing and restoring the window seem to repair the issue.

[ianyh]

Did a bunch of testing over the weekend. Some general notes.

• Switching between existing tabs in a window does not seem to generate created notifications. It does generate mainWindowChanged notifications.
• mainWindowChanged notifications are also generated when switching focus between windows. However, such events are preceded by a focusChanged notification so are relatively easy to distinguish from tab changes. I've tried a couple of time delta threshold. 1s was too much, as you would lose notifications if you switched between windows and tabs very quickly, but 0.1s seemed to be about right even for sense memory fiddling with the keyboard.
• mainWindowChanged notifications are also generated when switching between applications. Unfortunately, the applicationActivated notification comes after mainWindowChanged. I've been able to distinguish those events based on whether or not the corresponding NSRunningApplication is active. If it is not active then this isn't a tab change and we can ignore it.
• To actually handle tab changes I used a combination of factors to determine which "window" to swap positions with.
  • Fairly obvious ones like same application and screen.
  • Determining whether we think the window is on screen and whether it actually is. If we think it is active and it's not that means that the window disappeared, but we haven't reacted yet. In testing a few apps this seems to be consistent with native tab changes.
  • Frame comparison to make sure they are in the same place. This one required some error tolerance for Terminal windows as even switching between tabs you can get significant variation. I've been working with a 10pt tolerance which seems to be working well.
• Some behavioral notes about closing tabs
  • This does create a destroyed notification, but the mainWindowChanged to the other tab notification precedes it. I've been able to work around this because at the main window change time the destroyed tab is already invalid—more specifically, it has null window ID. You can basically just make sure it's the right application and swap the windows out. It does require something of a leap of faith as there is no longer any frame to compare and it will no longer read as active regardless.
• Still having some challenges with newly created tabs, but I haven't been able to work through them yet.

[ianyh]

Turns out my issue with new tabs was actually just needing to tolerate more height difference. Windows that go from not having tabs to having tabs can change the titlebar size which contributes to the overall differential.

[ianfixes]

Can you talk more about the need for height tolerance in general (like when it's used, and why)? This might be related to some other behavior I've noticed.

[ianyh]

@ianfixes The problem is that when you open a new tab it gets mostly treated as a new window, but the dimensions of the window can be different. This isn't true for all windows—e.g., Safari seems to not change height—but it's definitely true for Terminal windows.

[ianfixes]

If I'm reading this correctly, you are trying to determine whether mainWindowChanged refers to a new window or an existing window, and this is technically just a guess. Is that accurate (meaning the fix is just to get better at guessing)?

[ianyh]

It is technically a guess, yes. For most windows there's no need for the tolerance as the tabs will be in the same frame, but some applications (e.g., Terminal) have some quirks.