CJK

Hi @Bhishan,
 
Here's the equivalent code for Chrome that closes all windows and all tabs except the currently active one:
 
use Chrome : application "Google Chrome"
 
property |windows| : a reference to every window of Chrome
property |tabs| : a reference to every tab of |windows|
property tab : a reference to the active tab of Chrome's front window
 
close (|tabs| where its id ≠ id of my tab)
 
It's very similar to the Safari code, but Chrome requires that comparing tabs is done via their id property rather than directly as object references.

Yes, e.g.:
 
var app = Application('Usable Keychain Scripting')
app.currentKeychain.keychainItems.whose({name: {_contains: 'CK'} })()
 
I don't have Mojave but I'm hearing lots and lots of reports that it's ballsed everything up for AppleScripters, particularly as it no longer permits the use of scripting additions (people wonder why I never use them, and this is why).  However, as the Usable Keychain Scripting is an application, it can be scripted just like any other scriptable application that one downloads.

Hi!
 
One feature that doesn't seem to exist but I think would be great is the ability to make workflows app-exclusive, meaning that they'd appear only when a specified app (or several) is active and in the forefront.
 
For example, I'd like to make a ProTools workflow with several automation features triggered by various keywords, like "instrument" to create an instrument track, "duplicate X" to duplicate a clip a certain number of times, etc. I'd like to be able to use these keywords by themselves and not as an argument to a "ProTools" keyword ("ProTools instrument", or "ProTools duplicate X" would be much more bothersome to use), and here's the kicker, I'd like those keywords to not appear when I'm not in ProTools. Say I'm in Safari, if I type "instr", nothing appears, nothing is suggested.
 
You'd be able to specify in the settings of the workflow which app(s) it's enabled in.
 
I hope this was clear enough, but if not I'd be happy to try and explain it better.
 
Thanks!

Makes sense. I guess you could also use it to implement identical workflows for different apps (e.g. one for Safari and one for Chrome) that don't step on each other's toes.
 
That can actually already be achieved, though admittedly not without some indirection. Alfred already has all the necessary bits, they're just not in the right places to achieve this directly.
 

I wish you had asked this in your initial question.  It's extra work to go back and test a script in different situations after the fact, rather than had I known and been able to do the testing all at once.

I'm too tired to go and test anything for Chrome, but it would involve changing current tab to active tab, and utilising the id property of my tab to exclude it from the enumerated list of id of |tabs|.  Play around with it and just do trial-by-error.  That's what we all do.

Regarding Firefox, it won't work.  Firefox isn't scriptable (to any useful extent).

I'll check back in a couple of days and post a working solution for Chrome if you haven't got it figured out by then.

Next time, please include all your related needs in a single post.  Obviously, very disparate issues are still best posted as separate posts.

You could try this:
 
use Safari : application "Safari"
 
property |windows| : a reference to every window of Safari
property |tabs| : a reference to every tab of |windows|
property tab : a reference to the current tab of Safari's front window
 
close (|tabs| where it ≠ my tab)
 
I haven't really tested it though as I currently have a gajillion tabs open that I don't particularly want to close.
 
Also, don't use the Run NSAppleScript action.  Use the Run Script action and select /usr/bin/osascript (AS) as the chosen language.

@Bhishan, this is the general form the AppleScript code will take when trying to access a menu bar icon and its menu:
 
use application "System Events"
 
property P : a reference to the process named "Mathpix Snipping Tool"
property M : a reference to menu bar item 1 of menu bar 2 of P
property I : a reference to the menu item named "Get LaTeX" of menu 1 of M
 
click M
click I
 
It doesn't work for every single menu bar application, and there's an annoying 5-second delay between the first click command and the second.  This is a known, persistent feature that has various documented so-called solutions, none of which are reliable, but you can have a Google and see what works for you.
 
Don't forget to make sure Terminal (or whichever program is executing the above script) has accessibility privileges granted to it.

@MrAu,
 
Here's my humble offering, which may be no better or no worse than any others.  The workflow is downloadable here and will available for the next 30 days at which point the link expires.
 
Here's a screenshot of the workflow:
 

 
 
As you can see, it's very straightforward, so not much can go wrong.

Yes, everything I've supplied so far works on my system.  You should try to stop using console.log() to evaluate certain object types, because that can be the cause of some of the type conversion errors you saw earlier.  You can evaluate one object's true value and type simply by making that object the last line of the script, e.g. app.bookmarkFolders().
 

They’re not code blocks. Rather, it’s a text style change. I make them (and other text changes) via Markdown converted to BBCode with MarkdownTransform.

That's not the entire point. We can't magically write workflows in our heads. We normally need to run some code.
 
So you're expecting us to recreate your workflow for ourselves, simply in order to help you.
 
It's not particularly reasonable to waste other people's time like that. So please, upload the workflow.
 
 
 
You didn't answer the question. You're describing your proposed solution, not the problem you're actually trying to solve.
 
I appreciate the variables are coming from somewhere else. That doesn't mean they have to come via the clipboard history.

I’m quoting @deanishe, but my points are for @pauljacobson.
 
 
I’ll also add that it is not the domain of the asker to decide what is simple or not. For all we know, your workflow has an error in construction that you’re not seeing. Example: it has already happened that after an asker uploaded their Workflow, it was discovered it had an invisible character that was causing the bug. That’s an impossible bug to fix unless we have access to the actual Workflow as you made it.
 
 
This is important because for all we know you may be trying a convoluted solution when a simpler one is available. Trying for the harder solution wastes everyone’s time and makes your Workflow worse.

Yes, of course.
 
(30 minutes later of frustrating edits...)
to lookupTabWithURL(www) local www tell application "Google Chrome" set _W to a reference to (every window whose URL of tabs contains www) if (count _W) = 0 then return null set [W] to _W set T to the first tab of W whose URL is www return {wID:id of W, tID:id of T} end tell end lookupTabWithURL This one above returns both window and tab id numbers, should you need to target them in that manner, for example, to bring a window to the front, then switch the active tab.
to lookupTabWithURL(www) local www tell application "Google Chrome" set _T to a reference to (every tab of every window whose URL is www) if (count _T) = 0 then return null return item 1 of item 1 of _T end tell end lookupTabWithURL This one just returns the reference to the tab object, e.g. tab id 45 of window id 2088.  This can be used to target the identified tab and manipulate its properties or close it, for example.  It currently only returns the first matched tab, as that was the objective of the original script upon which this handler was based, largely as a demonstration on the different scripting methods.

Welcome,
 
When asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. Debugging can already be hard with access to the code, and you’re asking us to guess yours from a description. There are multiple places where your code or Workflow setup may be going wrong. Without looking at it we’re shooting in the dark.
 
In addition, please improve your description. You shouldn’t be asking what is wrong, you should be telling. Describe your goal, what happens (or doesn’t), and how you’re running it.

Read the Reporting Problems with Workflows topic, as it gives a nice overview on how to build an effective report.

If _W is a list, then it sets W to item 1 of that list.
 
It follows from the way one can assign multiple values to multiple variables in one go:
    set [a, b, c, d] to [1, 2, 3, 4]
which, as you might expect, assigns 1 to a, 2 to b, 3 to c, and 4 to d.
 
If the number of variables supplied is fewer than the number of data objects to store, the variables are filled in order, and the remaining (excess) data values are discarded.  So,
    set [a, b] to [1, 2, 3, 4]
assigns 1 to a, 2 to b, whilst the 3 and the 4 are ignored.
 
Therefore,
    set [T] to every tab in the front window 
will get a list of every tab, and assign the first one to T.  It works with nesting as well, so something like:
    set [T] to every tab of every window
assigns a list of tabs to T, but if you just want the first item from that list:
    set [[T]] to every tab of every window
will get you a single tab assigned to T.
 
P.S.  Or perhaps your confusion was because I utilise the square brackets for lists much more than other people, who typically favour braces.  For the most part, they're interchangeable as long as opening and closing sets match.  However, when coercing a list to a string, square brackets ignore text item delimiters completely, which can be very useful.  Square brackets can't be used for records objects, although list items in a record can use them freely.

Yes, of course.
 
(30 minutes later of frustrating edits...)
to lookupTabWithURL(www) local www tell application "Google Chrome" set _W to a reference to (every window whose URL of tabs contains www) if (count _W) = 0 then return null set [W] to _W set T to the first tab of W whose URL is www return {wID:id of W, tID:id of T} end tell end lookupTabWithURL This one above returns both window and tab id numbers, should you need to target them in that manner, for example, to bring a window to the front, then switch the active tab.
to lookupTabWithURL(www) local www tell application "Google Chrome" set _T to a reference to (every tab of every window whose URL is www) if (count _T) = 0 then return null return item 1 of item 1 of _T end tell end lookupTabWithURL This one just returns the reference to the tab object, e.g. tab id 45 of window id 2088.  This can be used to target the identified tab and manipulate its properties or close it, for example.  It currently only returns the first matched tab, as that was the objective of the original script upon which this handler was based, largely as a demonstration on the different scripting methods.

Double click it.

Looking at the source code, I can see why these users are experiencing these issues.  I downloaded the workflow and had a look at the AppleScript, which has quite a few issues with it.  @rodrigobdz, I note from your original post that Assistive Access is required to run this workflow.  Writing an AppleScript to achieve what you want here—namely opening a Chrome window/tab—shouldn't need to employ any accessibility features via System Events.
 
Here's your code that I copied from the workflow:
tell application "System Events" set myList to (name of every process) end tell if (myList contains "Google Chrome") is false then do shell script "open -a Google\\ Chrome --new --args -incognito" open location "https://google.com/search?q={query}" else tell application "Google Chrome" activate tell application "System Events" to keystroke "n" using {command down, shift down} open location "https://google.com/search?q={query}" end tell end if Google Chrome is scriptable, therefore you don't need to access System Events processes to determine whether or not Chrome is running.  Scriptable applications have a property called running that returns true or false depending on whether or not Chrome is running.  You can access it as with any other property, like so:
set isOpen to the running of application "Google Chrome" if isOpen then ... But, for this particular property (and a couple of others that return boolean values for the state of an application, another one being the property frontmost), you can use this very natural-language syntax:
if the application "Google Chrome" is running then ...  Following this, the reason the users are reporting two windows opening up—one of which might even be Safari instead of Chrome—is because you have one command telling a shell script to open Chrome in incognito mode (bearing in mind that launching a web browser usually opens a blank window); and you have a second command telling AppleScript to open location and this will always happen in a new window (that makes two windows), and it won't necessarily be Chrome. I believe it uses the system's default browser, which explains why there's a user reporting that your workflow opened Safari and Chrome for him (it did with me as well).
 
Basically, don't use open location when you want to target a specific web browser.  You could have used the same shell command that launches Chrome to get it opening a desired URL in the first window:
do shell script "open -a 'Google Chrome' 'https://imdb.com' --args -incognito" And, finally, for the last part of your script, you've once again elected to use System Events to issue a keypress that activates a shortcut to a menu item as a means to open an incognito window.  That's a bad method.  But, immediately afterwards, you use open location again, intending for the URL to open in the window you've just created.  For some users, it might do just that; but for others, it won't.
 
Basically, don't use open location, and don't use System Events for its accessibility hooks when you don't need to.  It's always a method of last resort, because it's very unreliable, and poor coding practice.  Do, however, use System Events for things like file and folder handling.
 
Anyway, here's how you first check to see if an incognito window is already open, then open a URL in a new tab in the existing window instead of creating a new window altogether, or, if an incognito window doesn't yet exist, opening a new URL in a new incognito window:
tell application "Google Chrome" set W to every window whose mode is "incognito" if W = {} then set W to {make new window with properties {mode:"incognito"}} set [W] to W tell W to set T to make new tab with properties {URL:"{query}"} close (every tab of every window whose URL is "chrome://newtab/") set index of W to 1 activate end tell In fact, on my system, that works regardless of whether or not Chrome is running, negating the need for all the bits that came before.  Thus, that ends up being the entire script.
 
I hope this helps you out, and helps resolve the issues your users were having.
 
 

My favourite thing about the Alfred forum is that there’s precisely two modes of syntax highlighting that seemingly cater for about 12 different programming languages: and those two choices are either Courier New all in black, or Courier New in black and green (but only quoted strings are in green).
 
My second favourite thing is that once you commit to the block of code you just wrote, you can’t edit it.  Or highlight it to copy it.  I love typing things out twice.
 
I love typing things out twice.

I searched this forum and didn't find any thread on this but I wanted to propose it for a long time now.
 
I very often use Discourse based forums like KM forum or Swift forum. And the experience in there is in many ways so much better than here. The interface is much cleaner, there is native markdown support, the search is better and more intuitive. I can't find anything this forum does better than Discourse can.
 
I also have been reading this forum for a long time and lack of markdown in writing things is a very obvious paint point. There was a thread made 2 hours ago that mentions this very problem. I myself am quite annoyed too by the fact that I am forced to use an external tool like MarkdownTransform just so I can in some comfort markup my text in this forum and run it through the tool later.
 
Also Discourse supports night theme which is a small cosmetic change but with Mojawe coming soon would be quite appreciated. 
 
It seems the big reason why this change can't be made is that you can't translate the content that is written on this forum to Discourse. Which if true, while sad, makes complete sense why we still use this forum software. But if that is not the case and there is a way to import all content into a new Discourse instance. I think this change would be really nice for the users.

https://github.com/vitorgalvao/alfred-workflows/tree/master/MarkdownTransform
 
I write in Markdown and convert it to BBCode because the editor on this forum is appalling.

Looking at the source code, I can see why these users are experiencing these issues.  I downloaded the workflow and had a look at the AppleScript, which has quite a few issues with it.  @rodrigobdz, I note from your original post that Assistive Access is required to run this workflow.  Writing an AppleScript to achieve what you want here—namely opening a Chrome window/tab—shouldn't need to employ any accessibility features via System Events.
 
Here's your code that I copied from the workflow:
tell application "System Events" set myList to (name of every process) end tell if (myList contains "Google Chrome") is false then do shell script "open -a Google\\ Chrome --new --args -incognito" open location "https://google.com/search?q={query}" else tell application "Google Chrome" activate tell application "System Events" to keystroke "n" using {command down, shift down} open location "https://google.com/search?q={query}" end tell end if Google Chrome is scriptable, therefore you don't need to access System Events processes to determine whether or not Chrome is running.  Scriptable applications have a property called running that returns true or false depending on whether or not Chrome is running.  You can access it as with any other property, like so:
set isOpen to the running of application "Google Chrome" if isOpen then ... But, for this particular property (and a couple of others that return boolean values for the state of an application, another one being the property frontmost), you can use this very natural-language syntax:
if the application "Google Chrome" is running then ...  Following this, the reason the users are reporting two windows opening up—one of which might even be Safari instead of Chrome—is because you have one command telling a shell script to open Chrome in incognito mode (bearing in mind that launching a web browser usually opens a blank window); and you have a second command telling AppleScript to open location and this will always happen in a new window (that makes two windows), and it won't necessarily be Chrome. I believe it uses the system's default browser, which explains why there's a user reporting that your workflow opened Safari and Chrome for him (it did with me as well).
 
Basically, don't use open location when you want to target a specific web browser.  You could have used the same shell command that launches Chrome to get it opening a desired URL in the first window:
do shell script "open -a 'Google Chrome' 'https://imdb.com' --args -incognito" And, finally, for the last part of your script, you've once again elected to use System Events to issue a keypress that activates a shortcut to a menu item as a means to open an incognito window.  That's a bad method.  But, immediately afterwards, you use open location again, intending for the URL to open in the window you've just created.  For some users, it might do just that; but for others, it won't.
 
Basically, don't use open location, and don't use System Events for its accessibility hooks when you don't need to.  It's always a method of last resort, because it's very unreliable, and poor coding practice.  Do, however, use System Events for things like file and folder handling.
 
Anyway, here's how you first check to see if an incognito window is already open, then open a URL in a new tab in the existing window instead of creating a new window altogether, or, if an incognito window doesn't yet exist, opening a new URL in a new incognito window:
tell application "Google Chrome" set W to every window whose mode is "incognito" if W = {} then set W to {make new window with properties {mode:"incognito"}} set [W] to W tell W to set T to make new tab with properties {URL:"{query}"} close (every tab of every window whose URL is "chrome://newtab/") set index of W to 1 activate end tell In fact, on my system, that works regardless of whether or not Chrome is running, negating the need for all the bits that came before.  Thus, that ends up being the entire script.
 
I hope this helps you out, and helps resolve the issues your users were having.
 
 

You're welcome, @Chamend.  On the surface, it functions identically to yours.  But under the hood, it targets the Safari application and its window(s)/tab(s) directly, so it won't even matter whether or not Safari is in focus, or even if the window were minimised (provided it is still the front window).
 
One of the reason using System Events in that manner is (should) be a last resort (but is done all too commonly to appear to be "the right way"), is because menu items are generally referenced by name, and these can change (by language and region), so is especially less portable if you plan to share workflows with others.  Keypresses to activate a shortcut is worse still, as these are customisable by design on macOS.  Both also require  Safari to be in focus, and application focus can shift unexpectedly, which would disrupt the script.
 
Just thought it might be useful for you to know all this if you're planning on venturing more into the AppleScripting world (which I encourage!).  I actually drafted out a much more complex script to open tabs in any specific Safari window or a new window, and provide the option of deciding whether to open it in the background or bring it to the front.  It benefited from being more robust and feature-worthy, but seemed a bit overly involved in this situation.  Nevertheless, if you want to take a look at it, I've posted it here for the time-being.

Basically, your script from this post reply here:
if you incorporate my suggested modifications, would now look like this:
on alfred_script(q) tell application "Safari" activate make new document with properties {URL:"https://www.apple.com"} my new_tab("https://www.google.com") my new_tab("https://stackoverflow.com") end tell end alfred_script on new_tab(www) tell application "Safari" to tell the front window to ¬ set the current tab to make new tab ¬ with properties {URL:www} end new_tab