deanishe

You can check whether it's enabled in JXA with: function run() { ObjC.bindFunction('IsSecureEventInputEnabled', ['bool', []]) return $.IsSecureEventInputEnabled() } FWIW, Chrome has quite a long history of failing to turn Secure Input off again. To fix it, you at least need to log out and log in again.

The workflow folder is the working directory when your workflow script is run, so pwd.

The way snippets work is that Alfred (or any other snippet app) monitors your keystrokes so it can tell when you've entered a snippet keyword. One of the key features of password fields (Secure Input) is that they prevent apps from monitoring your keystrokes. They wouldn't be secure otherwise.

It does, as far as I can tell. No, Alfred runs them the normal way. And it's hardly a big issue anyway. If you don't want the scripts to change, save them as .applescript (text) files instead of compiled scripts.

Well, it sounds like a permissions issue. It's hard to say anything concrete as your description is rather vague. Can you open any workflows in Finder?

I've noticed this. macOS appears to re-compile the script files (or otherwise do something to them) when it runs them.

No. Safari doesn't expose that information to external applications.

This feature has been requested several times before. The bottom line is that Firefox is just not a popular browser amongst Alfred users (< 5%). Please don't add huge "signature" images to your posts or your signature. Especially not both.

The proper and polite thing to do (for a project that hasn't been abandoned) would be to fork the workflow on GitHub (here's the link from the OP) and then submit a pull request with your changes there. It's certainly helpful to users to provide an updated version of the exported workflow, but makes life unnecessarily difficult for the workflow developer if you'd like your changes incorporated upstream.

@sballin I think at this point, it might be a good idea to start a separate thread for your workflow. Unless @surrealroad has abandoned his, this discussion doesn't really belong in his workflow's thread, imo.

Unlikely: with AppleScript most of the overhead is generally in connecting to the application in the first place. On my machine this typically takes ~0.3s. Reading the data will usually take a small fraction of that time unless you have an epic number of notes to read. The best way to handle this is typically to at least cache the data for several seconds/minutes, and better yet, to fetch them in the background while the live workflow works with the (very fast) cached data. Also, your AppleScript code is fundamentally broken because you're trying to create JSON by smushing strings together. That never works. If someone has a note that contains, say, a quotation mark (i.e. ") or non-ASCII text, your JSON will be invalid. It would be smarter to use JXA instead of AppleScript, as it has native support for JSON.

Just choose Slack a few times and it will be back at the top.

Hmm. The site told me to get lost, more or less.

To avoid encoding errors, change this line to: query = sys.argv[1].decode('utf-8') Unfortunately, this code is nonsense: you haven't understood what's going on: r = requests.post('https://cracked.to/search.php', data=payload) print(r.url) The URL you're printing doesn't contain the payload because it's a POST request. POST means, by definition, that the data are sent in the request body, not the URL. The request is almost certainly also failing because you need to be logged in to perform a search, and your workflow isn't logged in to the site.

Insert a Run Script in the workflow, using the language of your choice, that calls dirname on the path and passes it on (every reasonable language has a dirname function).