Andrew

@HeatherH I've just done a couple of simple tests with Preview.app in Catalina by opening a couple of images outside of Alfred. It can take a short delay (in my case a 5 seconds) before Preview updates its recent entries file, but then Alfred sees them fine. Is there a specific app you're trying recent documents with? Have you tried with Preview.app? Perhaps try removing Full Disk Access and re-granting it to Alfred?

@Anthott2623 Alfred has a built in Apple Music mini player, take a look here: https://www.alfredapp.com/help/features/itunes/ Cheers, Andrew

@alextran This isn't something I've heard being reported before. Alfred passes off behaviour to 1Password at the point you select an entry, so isn't in control of anything beyond this point. It might be worth popping a post on their forum to see what's up, they are extremely helpful and responsive! If you find out what's up, would you mind posting your findings back here in case it affects others?

@fms the usual cause of this is when there is a hotkey conflict, could you try temporarily changing Alfred to a different hotkey to see if it works. If you're using cmd+space, take a look at this help page for the 3 usual suspects: https://www.alfredapp.com/help/troubleshooting/cmd-space/

@snowfox From your description, Alfred isn't crashing, but iTunes is halting Alfred on the AppleScript interaction. The only known scenario for when this happens is when iTunes is waiting for user input. Next time restart, could you launch iTunes manually and see if it's requesting any input from you, e.g. a license agreement, or password request.

@HeatherH Have you assigned Full Disk Access to Alfred? https://www.alfredapp.com/help/getting-started/permissions/#full-disk

I'm using Mojave for Alfred's development, installed on my 2018 Mac Mini. Unfortunately, with the 2020-002 security update, it also did a BridgeOS update on the T2 chip which is causing a kernel panic every time the machine sleeps, or every time I shut it down. Looks like it is a widespread problem across various forums, which doesn't affect Catalina, so Apple don't seem to be in a hurry to fix it. *expletives removed*

@Mike Liang could you try quitting Alfred, then re-downloading directly from https://www.alfredapp.com/ and overwrite the current one in /Applications/ and re-launch. This could be a permissions issue which may get resolved by macOS seeing the app as a new app. If not, there could be a lower level permissions issue on macOS which is preventing the automatic connection between an app and the automation tab. Take a look at this blog post: https://bitsplitting.org/2018/07/11/reauthorizing-automation-in-mojave/ I believe AppleEvents is the command you need in terminal to specifically target automation: tccutil reset AppleEvents Or you could reset all permissions using: tccutil reset All Cheers, Andrew

@intafon if you right click on the keyword, you can add a note which is shown next to the workflow object. You can also set colours for objects which may also help you. Take a look at the built in workflow examples to see how we use notes and colours. Cheers, Andrew

@himat Alfred uses a very efficient in-memory method for doing snippet keyword lookups, and is very conscientious about battery / CPU usage. While having snippet expansion enabled does make Alfred look for keyword matches on every keystroke, the time taken to lookup per keystroke is always shorter than 1/10,000th of a second (and generally much faster than this), which is less than many routine macOS tasks which are going on the whole time under the hood. In my analysis, it makes very little difference if you have 10 or 1000 snippets. The most time consuming part is the macOS accessibility interactions. Cheers, Andrew

@christianboyce hmmm this is very strange indeed, and undoubtedly a bug in Contacts.app on Catalina. Alfred is simply calling the addressbook:// url scheme which is passed off to macOS. The behaviour after this is entirely outside of Alfred's control. The good news is this is super simple to reproduce, so it'll be easy for me to raise an Apple bug! Cheers, Andrew

@Luis Martins I've just tested in macOS 10.15.4 and Alfred 4.0.9 with Apple's TextEdit.app and am seeing recent documents, so this should still be working as expected. Does it work for any apps, such as TextEdit? or does it not work at all? Which versions of Alfred and macOS are you using? Cheers, Andrew

@JamieKeene I suspect that the actual update is failing to occur. Note that Alfred and the preferences are two separate apps contained in one package, so the main Alfred app may still be on an older version and thinking it needs update. Could you re-download the dmg directly from our website, delete Alfred.app in ~/Applications/ and replace with the version from the dmg. This should flush out any permissions issues which may be causing the issue. Cheers, Andrew

@luckman212 NOW this should be fixed

@deanishe I'll see what's possible for 4.1

It sounds like we need some way to call a Keyword Input directly from external AppleScript (via some sort of id, and providing an argument). This would allow Alfred to make that Input unique (much like pressing return on the result placeholder for that input, and the other results are removed), while populating the keyword and provided argument for the history.

Re-running a workflow based on a keyword is also fragile, as there may be multiple Inputs with the same keyword, and you'd get unexpected results (i.e. multiple workflows running on calling back for that keyword). It's better to use an external trigger wired into the Keyword Input and call back on that instead which takes you directly into the keyword you want by specific identifier.

https://www.alfredapp.com/help/troubleshooting/indexing/mdls/ I've changed the title and am moving this to discussion and help. Cheers, Andrew

@nikivi if you take out the net.daringfireball.markdown file type, is the file being found? The underlying metadata could be broken.

@vitor I just replied to the linked thread. It's unlikely that I'll update Alfred to treat invalid items as anything other than invalid, but I've offered a workaround. I'm gonna move this thread to workflow questions instead of closed, as it's interesting knowledge for others.

@vitor one way you could achieve this is make sure all items in your Script Filter have a UID, and make them all valid. Make a connection out of the Script Filter into a Junction, then configure the connection between the Script Filter and Junction to not close Alfred's window (you'll get a square instead of circle on the connection): This way, you actually WILL be actioning the items, but Alfred's window won't close. The next time you show Alfred, the selection will be taken into account when sorting the items. Cheers, Andrew

@luckman212 That's because I haven't fixed it yet

@bmazin thanks for the detailed reproducible cases, could you please update to the 4.0.9 b1143 pre-release and let me know how you get on! Thanks, Andrew

@40-02 Could you please update to the 4.0.9 b1143 pre-release, I believe I have a workaround to this

The focused app variable actually represents the currently focused app in the instant just before Alfred is shown with the custom hotkey. If the focused app variable was arbitrarily available at any point while the workflow is running, it would almost always return Alfred as being the currently focused app.