Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AltTab sometimes doesn't detect windows when they are opened already in fullscreen #1002

Closed
FredBonux opened this issue Jun 16, 2021 · 21 comments
Labels
duplicate This issue or pull request already exists enhancement New feature or request need breakthrough Need a breakthrough idea to move forwards

Comments

@FredBonux
Copy link

FredBonux commented Jun 16, 2021

Is your feature suggestion related to a problem? Please describe.
Sometimes not every window is shown in altTab but closing and reopening AltTab fixes the issue

Describe the solution you'd like
I think a simple "reload app windows" button in the top-bar menu could be helpful

thank you for your time

@FredBonux FredBonux added the enhancement New feature or request label Jun 16, 2021
@lwouis
Copy link
Owner

lwouis commented Jun 17, 2021

Duplicate of #647 and others

@lwouis lwouis closed this as completed Jun 17, 2021
@lwouis lwouis added the duplicate This issue or pull request already exists label Jun 17, 2021
@FredBonux
Copy link
Author

Hi, I don't think this is a duplicate.
I did not create this issue for the bug itself but to suggest a possible temporary solution

@lwouis
Copy link
Owner

lwouis commented Jun 17, 2021

Oh, I understand.

I'm sorry but that workaround doesn't seem worth it to me. It would probably be hard, even maybe impossible to implement. There is information that is lost if it's missed, like the event of a window being spawned. When AltTab is restarted, it will probably find all windows, but then it loses the recently-used order. After launch, windows order is their z-index, not their recently-used order.

The satisfying solution is to not miss the windows in the first place. Of course it could end up being impossible since macOS has no public APIs and AltTab is a mess of hacks with private APIs and SPIs, and playing with side-effects of the OS.

Other workarounds could be considered though. Maybe periodically checking for windows, in case we missed some. Maybe something else, I'm not sure.

I'll re-open the ticket and flag it as "breakthrough needed" in case somebody has a breakthrough idea to address this issue of missing some windows sometimes.

Finally, I'd like to note how hard it would be to test such workaround since missing windows happens randomly, and pretty much never on my machine.

@lwouis lwouis reopened this Jun 17, 2021
@lwouis lwouis added need breakthrough Need a breakthrough idea to move forwards and removed duplicate This issue or pull request already exists labels Jun 17, 2021
@lwouis lwouis changed the title Reload app windows list without restarting AltTab Workaround to prevent AltTab from missing some windows, sometimes Jun 17, 2021
@baggiponte
Copy link

Hi! I am having some similar problems with some apps too. When I use Preview or LogSeq, they appear on alt-tab as if the app were opened, but no window is (see screenshot). If I restart Alt-Tab then they appear.

Preview and LogSeq not working

@lwouis
Copy link
Owner

lwouis commented Jun 19, 2021

@baggiponte you're saying that at the time you took the screenshot, Preview had a window open? Could you share that as well?

@baggiponte
Copy link

Hi @lwouis, thanks for the prompt reply. Yes, at the time of the screenshot I had both Preview and Logseq windows opened. You mean sharing alt-tab panel when windows are opened? If so, I have attached the pic.

Screenshot 2021-06-19 at 08 24 03

I thought this happened because Preview windows were already open when I turned on my macbook, so I tried not to quit it and restart my machine, but they were correctly displayed.

@lwouis
Copy link
Owner

lwouis commented Jun 19, 2021

We has tickets in the past for apps that wouldn't show when launching/restoring their state at login-time. Do you think this issue happens to you often after you log in the computer? Another question: do any of these windows start on another Space, or in fullscreen?

Regarding login-time, things are pretty complex. I don't even know clearly the difference between:

  • This behavior here: System Preferences > General > Close windows when quitting an app. This can also be done case-by-case by holding the option key when right clicking the app icon on the Dock.
  • System crashes and when you reboot macOS asks you if you want to reopen the windows before the crash

@baggiponte
Copy link

baggiponte commented Jun 21, 2021

Do you think this issue happens to you often after you log in the computer?

I'd say all the time: I have just logged in and launched logseq (it was not a restored window) and the same issue appeared.

Another question: do any of these windows start on another Space, or in fullscreen?

I guess this must be it! I want windows to open fullscreen, so both Preview and Logseq opened in full. I tried to resize them, quit them and relaunch and AltTab did now display any issue!

@lwouis
Copy link
Owner

lwouis commented Jun 22, 2021

How do you set up Preview so that it opens windows fullscreen? The only way i know would be to open a window, fullscreen it, "quit and keep the windows" then re-open the app which will restore the windows directly in fullscreen. I don't know a way to have the first window open fullscreen. How do you do that? A video of the scenario would help me understand the steps you go through

@baggiponte
Copy link

Hi @lwouis! Let's cast aside Preview, I cannot replicate the scenario (i.e. it opens correctly) and let's focus on Logseq.

I am at odds. I do not really understand what is going on: sometimes Alt-Tab does not work. In the first video, I have just closed logseq fullscreen and relaunched it. It relaunches in fullscreen, reloads in fullscren and Alt-Tab shows a bug.

first_screncast.mov

The second video is taken right after the first one. Logseq is already open and I exit fullscreen (it may seem a bit confusing, because it is max width). I quit and relaunch it, so it reopens max width (but not fullscreen) and Alt-Tab works fine. Then I enter fullscreen, quit and relaunch, but Alt-Tab works. I do it once again and it works again.

second_screencast.mov

@lwouis lwouis changed the title Workaround to prevent AltTab from missing some windows, sometimes AltTab somtimes doesn't detect windows when they are opened already in fullscreen Jun 23, 2021
@lwouis
Copy link
Owner

lwouis commented Jun 23, 2021

From the first video, I can see many phases/animations happening until the window is finally ready and stable. These must create problems with AltTab by breaking the private API tricks we do to detect such fullscreen windows (again, no public API can do this job). The fact that the issue is not happening every time is probably due to data-races with system events and these animations.

I renamed the issue to be more specific. The next step is now for someone clever to figure out a workaround around this issue.

@foehnx
Copy link

foehnx commented Aug 6, 2021

I confirm this issue exists for me as well on a MacBook Pro M1 (MacOS 11.5.1) with reopened full screen windows, e.g. first-party applications Safari and Terminal, and third party applications, e.g. Notion, VS code.
It is not 100% consistent, but it happens more often than not, and if it occurs it is permanent (meaning window is not detected at a later point until AltTab is restarted).
Relaunching AltTab solves the issue always.

@johnbent
Copy link

johnbent commented Dec 9, 2021

I'm also seeing this issue. I created an Alfred workflow to at least restart AltTab when this happens.

@lwouis lwouis changed the title AltTab somtimes doesn't detect windows when they are opened already in fullscreen AltTab sometimes doesn't detect windows when they are opened already in fullscreen Dec 10, 2021
@btglr
Copy link

btglr commented Feb 1, 2022

I'm also having this issue pretty much all the time at login. Restarting AltTab fixes the issue, unfortunately I'm using multiple desktops/spaces so anything that is not on the current space doesn't generate thumbnails. If I quit and restart AltTab on a space, it only generates thumbnails for the windows on that space.

This was referenced Apr 21, 2022
@lukasszz
Copy link

lukasszz commented May 7, 2022

Confirmed.
AltTab doesn't register apps in fullscreen mode when starting or after waking up your MacBook.

  1. Open apps eg. PyCharm, Todoist
  2. Fullscreen the apps to make it own their own workspace
  3. You can switch to the apps using the AltTab
  4. Quit AltTab
  5. Open AltTab
  6. PyCharm and Todoist are not visible in AltTab
  7. Exit the fullscreen mode in PyCharm to turn into window mode - it is still not visible in AltTab
  8. Restart AltTab
  9. Now it is visible in the AltTab
  10. Make it full screen
  11. Still is accessible

@lwouis
Copy link
Owner

lwouis commented May 7, 2022

@lukasszz your scenario is different and looks more like you're seeing #1324

@lukasszz
Copy link

lukasszz commented May 7, 2022

@lukasszz your scenario is different and looks more like you're seeing #1324

But this is not a problem of the external display it happens when no external display is attached.

@lwouis
Copy link
Owner

lwouis commented May 7, 2022

@lukasszz neither this ticket nor the one I linked is related to external displays.

When you fullscreen a window on macOS, it puts it into its own dedicated Space. This creates all sorts of problem for AltTab since there is no public API to access windows in other Spaces than the current active Space. Thus we use private APIs and complex tricks to do the job. From macOS 12.2 onwards, it seems that one the private APIs were are using to make it happen has been broken by Apple, so users don't see windows from other Spaces (fullscreen windows are always on other Spaces).

That's why I'm guessing you're on macOS 12.2 or 12.3, and you see issue #1324.

This ticket here is more open windows that are restored after they were closed while fullscreen. See #1002 (comment) for more details

@lwouis
Copy link
Owner

lwouis commented May 26, 2022

Hey @koekeishiya, I was working on this, as well as #1467, and clarified/realized something:

When an app is launching, there is a period of time where it may create windows, but even if we are observing its window-created events, we don't get notified.

This happens for instance we you close an app without closing its windows, then when you relaunch that app, macOS will restore the windows. You could have 3 windows, but 0 notification about their creation. Instead today I'm doing tricks like looking at other events (e.g. new window focused for this app), and doing the AX call to list the windows of the app.

Problem use-cases where this tends to happen:

  • macOS restores the app windows
  • macOS open the app as a login item, with the checkbox Hide checked in Login Items
  • An app that launches with a weird pattern like a non-native app
  • An app that launches with a long splash screen (e.g. Gimp)

For instance, the scenario I'm running that trips AltTab:

  • Open a Terminal window
  • Fullscreen it
  • Open another Terminal window
  • Fullscreen it
  • Go back to the initial Space
  • Quit Terminal. It will close the 2 fullscreen windows on the other Spaces
  • Re-launch Terminal. macOS restores its 2 fullscreen windows. One of them gets focused
  • AltTab doesn't know about the other since it was on another Space, and we never got any AX notification

Do you know a better way to handle the windows created during launch?

Since we don't get the notification, I can only imagine either on a schedule, or during some other notifications from the app (correlation).

@koekeishiya
Copy link

koekeishiya commented May 27, 2022

In yabai I run the grab AX windows for applications every time a space is changed and look for new windows, because of the "only shows AX-refs for current space" limitation. You could do this as well, and it would let you detect fullscreen windows after it has been activated once.

To figure out if it is necessary to do the operation mentioned above (instead of doing it for every space change), you should be able to use SLSCopyWindowsWithOptionsAndTags and pass it all spaces as well as the connection_id of the process that you are interested in getting windows for, then you can figure out if this application in fact has a window that you do not currently have the AX-ref for. Then you can flag the application and run get AX + check_for_unknown_windows after the next space changed event, and either reset or keep the flag. Maybe even mark spaces as "visited" or something to prevent checking the same space multiple times.

I should probably make this change in yabai as well, instead of blindly running these every space change.

Edit: Made these changes for yabai in commit: koekeishiya/yabai@2e3fb4a

@lwouis
Copy link
Owner

lwouis commented May 28, 2022

I've dug into this again today, and come to the conclusion that it falls under the umbrella of #447. Indeed, the issue here is the following:

  • We rely on subscribing to an app's notifications to know when it creates a new window
  • When an app launches, its initial windows tend to not send such notifications. It could be a macOS bug, or it could be that technically by the windows are created right before we have a chance to subscribe to the app's notifications
  • Such initial windows can be on other Spaces than the current Space

This happens for instance when an app is opened, and some of its windows are restored. If they were fullscreen, they will be restored on other Spaces. Sometimes macOS will then automatically focus on another Space to show the newly open window, but there is an animation to get there which could mean we don't ask for windows during it, and we don't get the window.

More importantly, sometimes macOS will not focus such initial window. For example, if the restored app had multiple windows fullscreen. Then it may focus on of those Space, but not both.

Because we get no notification, and we don't travel to all relevant Spaces, we miss those windows. Let's thus focus the discussion in #447.

@lwouis lwouis closed this as completed May 28, 2022
@lwouis lwouis added the duplicate This issue or pull request already exists label May 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists enhancement New feature or request need breakthrough Need a breakthrough idea to move forwards
Projects
None yet
Development

No branches or pull requests

8 participants