I'm no longer able to use KM to work around Safari's infuriating "Do you want to allow this page to open…" nagging. I'm not sure when my previous "focused window changes" triggers stopped working, but they definitely have.
The issue appears to be that KM is no longer able to recognize the appearance of such dialogs. None of the "focused window" triggers are activated by them, as they're apparently not perceived as a change to the window, its title, or its frame. Is there any way for KM (or anything else) to take action based on the appearance of this unwanted interference?
[1,500 word rant on my absolute loathing of nanny culture redacted for the sake of sanity, taste, and the fact that profanity will only get this post suppressed. ]
I'm not sure if there's a way to know if one of these 'internal' dialog windows appears. In theory, Apple could have put a 'Always Allow' option in there, so Safari remembered and didn't bug you further. But then Apple (apparently) knows best.
I'd like to inform Apple that my mother is still living, and therefore I need don't a corporation to perpetually nag me in a futile effort to protect me from myself.
Thanks, but these aren't downloads but rather a requirement that Safari obtain permission before opening an app. But you're right - what's needed is a similar mechanism, rather than being nagged every single time forever. Unfortunately, no such mechanism exists. Hence my turning to KM.
G'ah! Yes, apologies for mis-reading the dialog you showed.
I guess the simplest way (I don't hold out much hope of Apple changing this behaviour, tbh) is to not use Safari...
But IIRC the "Cancel" and "Allow" are specifically coloured and spaced, so if this is part of a macro's workflow you should be able to use a click action with image detection.
Thanks for the suggestion, but the problem is not having a macro click the button - it's triggering a macro when the dialog appears. It isn't detect by any of the "focused window" triggers, and I've been unable to come with anything else.
As for dumping Safari, for me its advantages outweigh the irritant of this particular problem.
I see what you mean now. I only really see this with Zoom links, and when it was annoying me I just dropped the link onto another browser (eg Brave) that had already been authorised to open the app in question. That got just as annoying as clicking the dialog!
I guess you could do similar in a macro, or create a Safari service that would allow you to right-click a link to open it in the other browser -- but that seems just as much effort as simply clicking "Allow"...
I did quickly hack this up -- it triggers when Safari activates, then sits waiting for the dialog and clicks "Allow" when it appears. If you actually wanted to use this you should probably add a second condition to the image detection so it doesn't click "Allow" if the dialog is for a download rather than opening an app...
I appreciate your efforts (and not to beat a dead horse), but again, the problem isn't dealing with the dialog or its buttons, but triggering the macro. "When Safari activates" won't work. Safari is always active whenever the dialog is displayed.
Something like…
…will work, but that's so wasteful, brute force inelegant that I double over and retch at the very sight of it. With such a kludge active, the KM engine runs around 50% CPU on my system whenever Safari is frontmost.
So far as I can see, there's just no reasonable way to detect the appearance of the damned dialog. I've even explored a custom CFBundleURL scheme, but that merely moves the problem to a different but functionally identical dialog without solving it.
This strikes me as part of the larger issue of Apple's ever-increasing indifference to power users. For years, its ever more fractured, scatterbrained, weak efforts at automation have become increasingly bathetic with each passing day. (AppleScript… Automator… Shortcuts… What's next? A tin can and a string? A programmable fidget spinner?) An app like KM can only compensate for so much in the face of such willful indifference.
Hi @commiepinko With you initial question about the dialog popping up to give permissions for 1Password. What I am going to say is probably of no use and I don't want to waste your time. But it got me thinking if the problem might be to do with the 1Password setup rather than Safari.
I didn't reply straight away as I no longer have 1Password 7 on any machine... I'm now using 1Password 8 so, there was no way to test anything.
But both 1Password 7 and 1Password 8 need a browser extension installed in Safari so they can work more seamlessly and that extension (at least in 1Password 8) has to be given some permissions in Safari's preferences. Once that is set up, the only thing you should have to do is type in your 1Password master password to use 1Password in Safari for the amount of time you have set 1Password to not auto-lock. Safari shouldn't ask for permissions each time.
As I said, I don't have 1Password 7 anymore to give you better instructions (but maybe another user on the Forum does have it?).
Totally understand -- and if you look at the macro I posted it triggers when Safari activates and stays running until Safari is no longer active. Yes it hogs around 35% of a core when Safari is active, but in my "normal" use of Safari over the last couple of hours that's been unnoticeable. YMMV. That's with a 0.2s pause between loops, so minimal delay on detecting any "Allow" request.
And yes, I also wish we didn't have to resort to such chicanery...
]
With such a kludge active, the KM engine runs around 50% CPU on my system whenever Safari is frontmost.