Multiple instances/menubar icons #1840
Comments
|
If you double-click on AltTab multiple time, you will notice that it doesn't open multiple instances. Instead, it opens the Preferences window of the already-opened instance. This leads me to think that you have multiple different versions of AltTab installed on your system. Because you said "Over time, I seem to have accumulated", I'm also guessing that it may be because you use homebrew to install/update AltTab? I could imagine homebrew installs the various versions in various locations on your disk, and if all have the "Launch at login" checkbox checked, then they all separately launch at login (macOS launchd is launching them, technically). Did you use homebrew to install AltTab? If not, how do you update AltTab? Using the auto-update built into the app, or downloading new versions manually on the website maybe? |
|
I don't have AltTab installed via Homebrew and I can only find one copy of |
|
@mhamann could you please run and share the results of this command? ps auxwwwe | grep AltTabIt should tell us where the apps are launched from. |
|
I terminated all of the instances and restarted the process to get things working again, but when it occurs again I'll capture this additional info! |
|
I'm not going to release an update soon. So I'm afraid this issue may rot. What I can suggest is that you download an older version of AltTab here, you replace your current one with it. Then you open it and trigger the self-update. That's kind of artificially getting an auto-update to happen. It may trigger the issue, then you can inspect as we discussed above. |
@lwouis Not OP, but I've had the issue of having two AltTab instances a few times. Just now, after OS update, now I'm seeing: The CLI args are very different, but one thing suspicious to me is I'm out of my depth for what |
|
@darthwalsh that's quite interesting and confusing as well. I googled Could you please share these info?
Thank you |
|
@lwouis I was on AltTab 6.46.1. I saw there was an update though, so I updated to 6.47.0 just now. com.lwouis.alt-tab-macos.plist is: (upgrading didn't change the plist) |
|
I can confirm the issue of having 2 instances (but not more) from time to time as well. The way I can notice it is that once I press Alt+Tab the App window appears but starts flickering. Once the issue appears again, I'll do a ps auxwwwe and will share the results. I think I downloaded the first version from the Website and since then I use the auto-update procedures once an update is available. |
|
My post #2510 has been closed & merged into this one but it only appeared after upgrading to macOS 13.3.1 using 6.56.0 Now happens on every startup. |
|
@Neoconair from what i've seen so far, my best guess is that there is a bug in macOS that affect only certain people who fall in a narrow path of being at version X and upgrading to version Y, while having a certain version of AltTab. We can't reproduce it consistently, and people on the latest AltTab + macOS don't have this issue. Or have it then don't have it again after they fix it. Nothing much we can do here unless someone has more data to help characterize the issue |
@lwouis by "fix" do you mean the workaround of killing both AltTab processes, then launching the AltTab Application? I'm not seeing another fix on this thread.
I'm wondering now if the When I search for some other brew apps I've installed, many have an I'm seeing steam and karabiner also have services with the Something I noticed last time I was debugging: So, right after The file |
|
Hi @darthwalsh, This is interesting. Here is my setup:
Now comes the interesting part. Using ~
$ launchctl list | grep alt-tab
63429 0 application.com.lwouis.alt-tab-macos.32215388.32215394
63613 0 com.lwouis.alt-tab-macos
~
$ launchctl print gui/$(id -u)/com.lwouis.alt-tab-macos | head -8
gui/501/com.lwouis.alt-tab-macos = {
active count = 4
path = /Users/lwouis/Library/LaunchAgents/com.lwouis.alt-tab-macos.plist
type = LaunchAgent
state = running
program = /Applications/AltTab.app/Contents/MacOS/AltTab
inherited environment = {
~
$ launchctl print gui/$(id -u)/application.com.lwouis.alt-tab-macos.32215388.32215394 | head -8
gui/501/application.com.lwouis.alt-tab-macos.32215388.32215394 = {
active count = 4
path = (submitted by runningboardd.372)
type = Submitted
state = running
bundle id = com.lwouis.alt-tab-macos
program = /Applications/AltTab.app/Contents/MacOS/AltTabSo the Could you please show me what similar commands show in your case, when you have 2 instances running at the same time? I'm especially interested in the Thank you |
My current assumption is that the 2nd instance is related to a system restart. Could it be that the option to restart all applications (in MacOS) on restart is cause for this issue? |
|
I have the same issue! I feel this should be treated as a bug. Two thoughts:
Seems a inherently risky to not have some sort of safeguard against this. |
|
I looked into Regarding the issue in general, I don't know how easy it would be to handle with new logic around the launch code. Some scenarios to keep in mind:
The restart code is the following: func restart() {
// we use -n to open a new instance, to avoid calling applicationShouldHandleReopen
// we use Bundle.main.bundlePath in case of multiple AltTab versions on the machine
Process.launchedProcess(launchPath: "/usr/bin/open", arguments: ["-n", Bundle.main.bundlePath])
App.shared.terminate(self)
}Notice how we first launch another instance, then we terminate the current instance. I'm not sure how we could do it differently. Finally, the identity of an app is not that simple, I believe. There is the It's not an easy problem. If you have an idea on how to tackle this, please share a PR, and I'll gladly review its code 👍 |
|
Hmm - what if we had a toggle for the first one? I think a majority of Macs tend to be single user devices! That might be the quick win :)
|
|
There would still be the issues I mentioned about Sparkle and permissions, which require a restart, and that restart being implemented as "start new instance, then stop current instance". |
@lwouis sorry for the delay. My work switched me from Intel macbook, to a new Apple Silicon Macbook. On this new machine, I have never had the problem with multiple AltTab instances. On this new machine, I installed AltTab through brew's To anybody else having this problem with multiple instances, I wonder if a workaround to uninstall AltTab, ensure both the above launchctl are deleted, then installing latest AltTab, would solve the problem? |
|
I have AltTab start when I boot up my Mac and I have it stay in the menu bar. However, when I boot up my Mac from a powered off state, instead of it appearing once in the menu bar, it appears twice. AltTab version: 6.65.0 |
|
I'm not sure whether this affects anyone else, but I realized I had both checked the option to "Start at login" and added AltTab to my "Open at Login" Login Items in the General Settings. This resulted in the same problem. I've tested removing the latter and leaving the "Start at login" checked, which resulted in only one instance and no flicker. I don't remember if I manually added it to the Login Items or not. |
|
One way to launch 2 AltTab instance at once, as we saw from #3550 (comment), is to:
I can't think of a reason why users may want multiple AltTab instances running. We could implement a check a launch, so AltTab refuses to launch if it detect another instance. However, this could have issues:
|
In my experience: either try to take a named semaphore or an exclusive file lock (possibly those have the same underlying implementation on macOS). This avoids any race condition or needing to decide which instance is "bad." As a first pass, printing log messages about parent process sounds useful, so the next time "[In-app feedback]" gets created we can start to see the root cause? |
I don't think we could implement something as simple as "first instance gets the spot; other instances will quit". Let's take the example I shared above: the user has checked the checkbox to get AltTab to launch at login. At the same time, they've added AltTab to their Login Items manually. Which one of those should we keep? Also should have the dance of both instance trying to launch, and the second fails, on every login? Or should we take more actions, and try to disable secondary launches root cause (e.g. remove the Login Items programmatically, or remove the LaunchAgent programmatically? |
|
I also encountered the flickering problem caused by multiple instances of AltTab. I did some digging and came across this SO article: https://stackoverflow.com/questions/74714844/how-to-use-named-object-in-macos-to-limit-app-instances |
|
Thank you @Thomas1664 As I stated above, the issue is not that we can't prevent secondary instances from launching. I think we could do that if we wanted. The issue is then if a user has a wrong setup, 2 instances would try to launch each time, and one would auto-close. I think a proper solution would be to attack the root cause and disable either the Login Item, or the LaunchAgent, if we notice that both exist. In the meantime, the best is probably to add logs to see where these instances are coming from. @Allsochen has added a logging library on the branch we are working on. I think after we merge it, we should use it to add a new log on launch, showing the parent process / the origin of the launch. Thank you |
Describe the bug
Over time, I seem to have accumulated multiple Alt-tab instances. I'm not sure where these all came from--I didn't do anything to launch them as far as I know. As seen below, multiple menubar icons are present as are multiple entries in Activity Monitor.
I'm not sure how to reproduce this, but I think it occurred within the last 24 hours. My machine's current uptime is roughly 7 days. I believe I've seen this before, but it's not consistent.
All of the running processes have a parent of
launchd.I apologize that this isn't a more helpful bug report.
I'm using version 6.46.0.
Screenshots / video
Steps to reproduce the bug
The text was updated successfully, but these errors were encountered: