I used this macro often :
But now using it returns me this text :
/var/folders/1h/fwb8ld896k92llzx3vytcmtm0000gn/T/Keyboard-Maestro-Script-232D23D1-BE71-4063-91B6-0F79FE72527A:36:39: execution error: Safari got an error: Can’t get document 1. Invalid index. (-1719)
Did something change with Safari?
This macro is a must have for me. Would appreciate any help on this.
Your AppleScript action works fine for me.
But Safari sometimes can have some invisible documents/windows. Maybe it is related to that.
Have you tried to restart Safari?
Here a couple of variants from another thread. They are all working fine for me:
___ [test] Safari URL.kmmacros (3.5 KB)
 Safari 10.1.1, macOS 10.12.5
Why use AppleScript for this simple task, when you can use the KM token %SafariURL% ?
You might also be interested in the other Safari Tokens:
(Chrome has a similar set)
Does the %SafariURL% token work?
It might fail in the same way since it is a wrapper for AppleScript that is not much different to
tell app "Safari" to tell document 1 to URL
It is slightly more complicated to deal with Safari not running, but essentially the same.
Although “document 1” and “front document” might five different results.
%SafariURL% works. It was a bug related to this it turns out. After restarting laptop it started working again.
And thank you @JMichaelTX, I will make sure to take look at these. They seem really useful.
I think I could reproduce your problem by simply starting a second instance of Safari:
What I observe then is is:
- The AppleScript URL actions (including the %SafariURL% token) always refer to the second instance of Safari.
- It is irrelevant which of the Safari instances is frontmost.
Closing the second, document-less Safari instance makes the AppleScript actions work again.
I would strongly advise people never to launch two instances of any Mac application unless they know for sure that the application is designed for it (I believe Chrome is).
Almost no Mac applications are written expecting to be launched multiple times, and there are many ways this could go wrong, including corrupting preference or cache files, overwriting settings or documents, etc.
Mac applications are simply not written to allow for this kind of behaviour, they expect to be the only instance of themselves running in the user space (you can have multiple instances across multiple users, obviously).
I completely agree. According to the link @nikivi has posted above it seems the issue came to life because of an Alfred workflow explicitly dedicated to opening multiple instances of a program:
The open command gives us extra control when opening apps, such as making new instances or relegating to the background. This Workflow emulates those options with File Actions.
It seems the author of the workflow forgot to mention possible side effects