Caps Lock indicator is considered as a window

[np25071984]

Your environment

• AltTab version: 6.65.0 (2024-01-29)
• macOS version: Sonoma 14.2.1

[lwouis]

Hi,

This happened during the Sonoma beta a while ago, then Apple fixed it. Are you on the public release or some beta version?

Thank you

[np25071984]

I am on the public release.

[lwouis]

I was able to reproduce it on macOS v14.1.1.

I can't reproduce it with Chrome, but I can with Terminal. I expected that either every app has the issue, or none has the issue, since this indicator is an OS-level UI element.

[np25071984]

Was able to reproduce it on:

• terminal
• Firefox
• Google Chrome
• Slack
• vscode

For me the bug looks quite consistent.

[lwouis]

I tried to debug the window, to see if there is anything we could use to filter it out. As I did this, I stopped being able to reproduce the issue, with any app.

When the issue stopped happening, I could see that this blue-indicator window has level == 3, which is the backstopMenu level.

I suspect that sometimes, the OS puts this popup on the wrong level, and this is when AltTab shows it. Then it gets fixed doing something, like changing window focus or something else, and then AltTab stops showing it.

AltTab is most likely doing its job at reporting windows, and the OS is sometimes rendering these on the wrong level, which makes it show in AltTab.

Not sure what we can do here to mitigate this.

[mathieuades]

It seems to happen with chrome when the cursor IS in a field (like google search field) with Caps Lock enabled and then you do Alt-Tab.
If the cursor is not in a field, the issue does not appear.
I hope this can help.

This is very annonying. I hope you can fix it or find a workaround...

[lwouis]

I've debugged this a bit more:

• It still happens on macOS 14.5, so Apple hasn't fixed it, and it looks like they won't
• It's still Apple fault. macOS spawns a mini-window for the indicator. AltTab reports it as it should. macOS shouldn't create such window. They use the subrole AXDialog when clearly it's not a dialog. It's some HUD at most. The user is not expected to drag this window around for example like you can with a dialog.
• Different apps, even when from Apple, behave slightly differently. For instance, Terminal has its indicator on level 3, which makes it not appear in AltTab, whereas Chrome or TextEdit has theirs on level 0, so they show up in AltTab

From AltTab's perspective, these windows are not from "the OS". They are created by their respective apps. So there is no way for us to blacklist them transversally. Here's an example of the data we see:

App	Window title	Window level	Window subrole	Window role	Window size
Chrome	""	0	AXDialog	AXWindow	84x77
TextEdit	""	0	AXDialog	AXWindow	84x77

Let's look at the pieces of data one by one:

• The app name is not useful. As I said, the window is going to be created by every app themselves, not by some system-level central service => can't discriminate based on that ❌
• The window title is empty. It may look like we could remove empty title windows, but we can't. It's legitimate for an app to have a window with no title. It happens for many apps, for instance when you create a new empty document => can't discriminate based on that ❌
• Role Window + Subrole Dialog. We show windows which are either "standard window" or "dialog". In normal language, we show windows and dialog. Think a normal big window, and a small dialog with the traffic-light buttons on it. This is what most people expect should show up in AltTab. Not HUDs and weird floatty UIs => can't discriminate based on that ❌
• Window size: we could discrimate on the size. In other words, we could filter out very small windows. In fact, we used to do that. We used to hide windows which are < 100px high or < 100px wide. Then we were hidding Finder file copy dialogs. You can see the story here: File copy progress windows are not picked up #1466. Also important to note here: we can't really hard-code something like "if the window is exactly 84x77, then let's hide it". The window may be of various dimensions depending on the monitor used, it's DPI, the specific macOS version used, etc. If we would discriminate here, it would be some broad rule to hide small windows, not a specific snipe for this caps-lock window, which would be too brittle.

I don't know how we could elimate these caps lock "windows" from showing. Does anyone have an idea about how to do it? It seems to me that only Apple could fix this issue correctly.

[ShlomoCode]

@lwouis What about filtering by minimum width OR minimum height (it will be enough for the window to be either high enough (NSAlert for example) or wide enough (Finder file copy windows for example))? Won't that solve the false identification?

[lwouis]

Thank you for the suggestion @ShlomoCode. I think it's the best compromise here. It will preserve Finder's file copy dialogs while hidding the caps-lock indicator. It will also

I'll add this change to the next release 👍

[mathieuades]

Works perfectly ! Thank you.