Thanks @CJK. @Gevor Due to heavy workload I can't currently commit to finding a fix for this bug but I am, like I previously said, open to contributions from the community.
Let me save everyone a 97MB slow download of a 1-minute video that could easily have been a 3-second GIF, that could easily have just been some words: when launching Chrome in incognito mode via the workflow being discussed in this thread, it does, indeed, open an incognito Chrome window, but also appears to open a normal Chrome window behind it.
(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.
@CJK @deanishe Thanks for taking the time to review the workflow so thoroughly! I really appreciate it.
@Gevor @politicus I'll release a revised version of the workflow this weekend. Stay tuned.
@rodrigobdz
I am sorry, my bad. I checked again and the behaviour of the workflow is not really how I described it. It does open one window of Chrome and it is in incognito mode. But for some reason it also opens Safari window. I took it for Chrome when I first tried the workflow.
One additional tip: Don't use {query}. It's hacky and finicky. Use "with input as argv" instead, and add a top-level on run argv handler to your AppleScript:
on run argv
set theQuery to item 1 of argv
...
...
end run
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.
rodrigobdz got a reaction from Gevor in Workflow: Chrome Incognito - Open Google Chrome in Incognito mode.
