buschtoens
commented
3 years ago Whild trying to provide easy reproduction steps, I also found the fix. 😂
This is the command in ~/Library/Application\ Support/com.github.domt4.homebrew-autoupdate/brew_autoupdate that's triggering the notifier:
/usr/bin/open /usr/local/Homebrew/Library/Taps/homebrew/homebrew-autoupdate/notifier/brew-autoupdate.appYou can reproduce the issue by executing that command.
Luckily, the fix is simple. man open reveals two interesting flags:
-g: Do not bring the application to the foreground.-j: Launches the app hidden.
And indeed, applying either of them resolves the issue.
I can't tell any difference between -g and -j though. I would expect -j to prevent the 🍻 icon from showing up in the dock, but it still shows. There are also no other noticeable differences in behavior.
Anyway, #72 is ready and adds the -g flag.
The new
brew-autoupdate.appnotifier (#43) "steals the focus" when displaying a notification.For as long as the 🍻 icon is being displayed in the macOS dock (about 3 seconds for me), the focus is removed from the prior window and instead moved to
brew-autoupdate. Once thebrew-autoupdateapp closes (i.e. the dock icon disappears), the focus is returned to the prior window.(Notably, the notification banner itself outlives the
brew-autoupdateapp instance by a few seconds, but I doubt that this is of any relevancy here and just due to how macOS handle notifications.)You can manually return the focus while
brew-autoupdateis still running by clicking or Cmd+Tab-ing to where you want to go. However, since the whole stunner just takes about 3 seconds, you usually don't realize what's going on, before everything is back to normal again.This is quite an annoying bug though, especially if you have a high update frequency. I spend most of my time in VS Code furiously bashing my keyboard, when all of a sudden I get spammed with the system alert sound effect, while all my keystrokes vanish into
/dev/null. Instant flow killer. 😄