I’ve suddenly started noticing a weird behavior on two of my Macs: they regularly pop up the “Choose Application” window that gets triggered when an automation tries to interact with an app that it can’t find. In this case, they’re looking for Vivaldi or Brave:
I have never installed or used Vivaldi or Brave on either machine, and I’m at a loss for what might be causing this. I’m curious if anyone has seen anything similar or has any ideas.
One thing these two Macs have in common is a synced Alfred configuration. There haven’t been any intentional configuration changes recently, and I’m not aware of any workflows which would obviously cause this, but that’s the only lead that sprang to mind.
That looks to me like a hard-wired application link in whatever automation actions you’re trying to use in Alfred. Unfortunately I don’t use Alfred these days, so can’t advise on how to edit the automation to use your default browser.
To be clear, this isn’t something triggered when I explicitly fire an automation — it happens spontaneously in the background, often when I’m away from the computer. I’m just at a loss for what common tools one might have installed that are probing for different browsers all the time. Alfred was just a guess, since many things in Alfred use Apple Events / AppleScript, which triggers this prompt when attempting to communicate with an app that it can’t find. But it seems totally divorced from any explicit action on my part.
You can lock the Accessibility Inspector on the item under the mouse to examine its attributes, perform its actions, and access its parent and children (if any), by pressing Command-F7. When you do this, the Accessibility Inspector display pauses, allowing you to move the mouse without changing the object on which the tool is focused. In the main utility window, you can go to the object’s parent, children, or other related objects, such as the containing window or the top-level app (AXApplication ).
Thanks @JohnAtl — great tip. That indeed might have helped (not sure if that window would have an identifiable parent, as the app in question is headless so selecting the window doesn’t give focus to a specific app / change the menu bar / etc.), but I believe I solved the mystery and resolved the issue just before seeing this.
The offending process seems to have been Freedom. I wound up using the brute force approach of greping for the more unique browser name strings (“Vivaldi”, “Sidekick”, “Microsoft Edge”) in every file under /Applications and ~/Library, and sure enough, the Freedom.app binary contains references all of them (and looking at where they occur they all seem to be used in the same way as an appName argument to something, which I presume is ultimately an AppleEvents call). The issue seems to have been resolved in a recent update to Freedom, so after forcing updates I haven’t seen the phantom alerts since.
Update: The Accessibility Inspector approach does seem to work! I just reproduced the headless-app-showing-a-selection-dialog-for-a-missing-app issue with a trivial AppleScript saved as an app (which I modified to LSUIElement = true) and the inspector was able to see the parent app of the phantom dialog window perfectly.