Closed buschtoens closed 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.app
You 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.app
notifier (#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-autoupdate
app closes (i.e. the dock icon disappears), the focus is returned to the prior window.(Notably, the notification banner itself outlives the
brew-autoupdate
app 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-autoupdate
is 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. 😄