paulw

I appreciate the direction to a working script, @simoncveracity! It looks like that script has been updated. It can be found here: https://github.com/MrSimonC/Toggle-Mac-Function-Keys/blob/main/Toggle Function Keys.scpt Working on macOS Sonoma.

@vitor looks like it was fixed in the latest version of Orion RC. Sorry for the trouble!

Thanks. That does work, using "Orion RC" as the custom browser. Hopefully I can find a way to get the "Current Front Browser" working again with Orion RC, since it has the advantage of also working with other browsers I might have open.

Thanks @vitor. I won't ask you to spend time troubleshooting a browser that you don't have access to, but just FYI, I used this script to confirm that kCGWindowLayer is 0 and kCGWindowOwnerName starts with Orion (Orion RC). I'm not sure what you mean by this. Could you explain?

Thanks. It's the same issue as before: "Current Front Browser Tab" fails with Task Error: arm/get-frontmost-browser.swift:32: Fatal error: Did not find a supported web browser ../../../../com.alfredapp.automation.core/safari/.common/tabs-current: execution error: Error: Did not find a supported web browser (-2700) I'm on Alfred 5.1.4 and MacOS 14.3. Other Automation Tasks involving front browser run into the same error Edit: and I'm using v 2024.1 of Automation Tasks

Hello @vitor, unfortunately Frontmost Browser is no longer working again with the latest update of Orion RC. I checked the text samples that I sent you above, and none of those seem to have changed in the new version (except I didn't check <key>DER-Encoded-Profile</key>).

That did it @vitor! Thank you so much for looking into this and making the change!

If there's a way I can help you figure it out, I'd be happy to. I don't know if the cause could be this simple but using Filemerge, I notice that in Contents/Info.plist for each app, Orion's includes <key>CFBundleExecutable</key> <string>Orion</string> <key>CFBundleIconFile</key> <string>AppIcon</string> <key>CFBundleIconName</key> <string>AppIcon</string> <key>CFBundleIdentifier</key> <string>com.kagi.kagimacOS</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>Orion</string> while Orion RC's has <key>CFBundleExecutable</key> <string>Orion RC</string> <key>CFBundleIconFile</key> <string>AppIcon-RC</string> <key>CFBundleIconName</key> <string>AppIcon-RC</string> <key>CFBundleIdentifier</key> <string>com.kagi.kagimacOS.RC</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>Orion RC</string> Also in Contents/embedded.provisionprofile some of the differences are: Orion: <key>AppIDName</key> <string>Kagi</string> ... <key>DER-Encoded-Profile</key> <string><<a long string>></string> ... <key>com.apple.application-identifier</key> <string>TFVG979488.com.kagi.kagimacOS</string> ... <key>Name</key> <string>Kagi macOS</string> and Orion RC: <key>AppIDName</key> <string>Orion RC</string> ... <key>DER-Encoded-Profile</key> <string><< a different long string >></string> ... <key>com.apple.application-identifier</key> <string>TFVG979488.com.kagi.kagimacOS.RC</string> ... <key>Name</key> <string>Orion macOS RC</string>

Oh I see. It seems that as long as I'm using Orion RC, I'd have to adapt the workflow to use the Webkit Automation Tasks, instead of Frontmost Browser Tasks. That's too bad, because I'd prefer to be able to use the workflow with non-Webkit browsers as well. Yes, you're right, Orion RC is available on the paid plan.

Orion RC gives me "Orion RC is not a supported browser". Can you explain where the "Custom..." choice is to be found? I don't see it in the task options

@vitor thanks for the explanations. I see now that yes it does work with Orion. Thank you! I'm currently using the Orion beta for subscribers (Orion RC) and it's not in Alfred's list. No worries, I wouldn't expect the team to add it, but in case you do, please let me know

Thanks! Works great without the need for the osascripts now. The only issue that I'm having is that I'm using Orion browser (actually, the Orion RC version) and I get the error Task Error: arm/get-frontmost-browser.swift:32: Fatal error: Did not find a supported web browser I realize there are a ton of browsers out there, and some come and go, and it might be a chore to keep Alfred managing a list of them. Perhaps: 1. Orion and Orion RC be added to the list of supported browsers, or 2. Possibly there's a more global way for Alfred to recognize browsers (Orion for example is basically Webkit plus added stuff)? or 3. Users could specify an app as a browser in Alfred preferences (similar to how Choosy.app allows you to specify an app that it may not have detected as a browser)?

Thanks for the reply and explanation, @vitor! Great to hear, I'll look forward to it!

Thanks @Stephen_C. What you described is an example of the issue, but unfortunately not a solution for what I was looking for/expecting, which is that the automation would work even when an app that isn't a browser is active. I'm was trying adapt @dfay's very useful Browser snippets workflow to work with any browser, using Alfred's built-in automations rather than adding a bunch of extra scripting to account for other browsers. I would have expected "Current Frontmost Browser Tab" to basically: - determine what browsers are running - determine which window among those browsers is in front of the others - return the URL and/or Title of the current tab from that browser window This would allow the action to return the active tab of whatever browser I was most recently working with, even if I'm using a different app. Ause case would be to grab the url and title from the tab and paste it into a text document, for example, with one quick keyboard shortcut or snippet. Instead, "frontmost browser" really seems to mean "frontmost app, which also must be a browser".

I'd like to get the title and url of the active tab in the frontmost browser, using the automation task "Get Current Frontmost Browser Tab". I expected the automation to detect which browser is frontmost, no matter what app is active, but it doesn't seem to work that way. For example, if I make a simple workflow with a keyword to trigger "Get Current Frontmost Browser Tab", and trigger it from the Alfred UI, the debugger shows [Automation Task] Task Error: ../../../../com.alfredapp.automation.core/safari/.common/tabs-current: execution error: Error: Error: Alfred Preferences is not a supported browser: Safari, Webkit, Orion, Google Chrome, Chromium, Opera, Vivaldi, Brave Browser, Microsoft Edge, Arc (-2700) Is that expected? It seems like it would be more useful for the automation task, and others like it, to find open browsers in the background, find the frontmost one, and get its active tab.

Brilliant! That worked, thanks @Vero. Just shifting it down to "Faster" solved the issue. I'll update the Orion bug report with that info.

Just noticed there's an open issue about this at Orion's feedback site

I've been using Orion Browser recently, which is Webkit based, and running into an issue with Alfred snippet expansion. I have a snippet for my email address for example, like @@em which expands into my full email address—let's say "my@email.com". In other browsers, including Safari, this works with no problem. In Orion, though, it expands to "@@my@email." If I use macOS's built-in text expansion, there's no such issue. I've tried disabling all extensions in Orion, but no luck. Any ideas?

This is awesome. Thanks for the workflow!

I just switched to Obsidian, thanks for this workflow!

@vitor, wonderful, thanks so much for clarifying. Now I understand the issues much more clearly!

Oh, ok, I would have thought that Alfred would be able to make use of the user's PATH, instead of having to explicitly define it in the scripts. Is there a reason why it can't?

Alex Chan's workflow, which this one was forked from, was just updated to use Python instead of PHP, and it works with Monterey now

I have php installed via Homebrew, and I'm on Alfred 4.6 on Monterey, but workflows using php are breaking. Confirming that php works in the command line on my machine: % which php /usr/local/bin/php % php -r 'echo function_exists("foo") ? "yes" : "no";' no% According to this blog post, "If you install PHP (e.g. via homebrew), most PHP-based workflows will continue to work without an issue, as the workflow script objects in Alfred 4.6 have been updated to be aware of alternative bin paths." But in a bare-bones Alfred workflow with language set to bin/bash: php -r 'echo function_exists("foo") ? "yes" : "no";' gets me "line 1: php: command not found" in the debugger. Am I misunderstanding something?

Thanks! By the way, I did a file comparison between the old and new versions, and you changed export_shortcuts to export_shorcuts. Doesn't seem to be a problem, since it's consistent, but just thought I'd let you know 🤓 Never mind, had that completely backwards. Thanks for your very useful script!