Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epichrome apps no longer respond to Chrome's AppleScript API #177

Closed
zzamboni opened this issue Nov 20, 2018 · 22 comments
Closed

Epichrome apps no longer respond to Chrome's AppleScript API #177

zzamboni opened this issue Nov 20, 2018 · 22 comments

Comments

@zzamboni
Copy link

Epichrome apps used to respond to the Google Chrome AppleScript interface, which I used extensively to automate and integrate them.

Recently I switched laptops and in the process recreated a few of them. Now I've noticed that they no longer seems to respond to the Chrome AppleScript API. For example (I have an Epichrome app for OpsGenie):

> osascript -e 'tell application "Google Chrome" to URL of active tab of window 1'
https://www.google.com/
> osascript -e 'tell application "OpsGenie" to URL of active tab of window 1'
38:48: syntax error: A property can’t go after this identifier. (-2740)

I've also tried specifying the ChromeEngine app inside the application bundle, but I get the same:

> osascript -e 'tell application "/Applications/OpsGenie.app/Contents/Resources/ChromeEngine/OpsGenie.app" to URL of active tab of window 1'
101:111: syntax error: A property can’t go after this identifier. (-2740)

Is it still possible to make this work? I found this feature extremely useful.

@marlowe310
Copy link

marlowe310 commented Dec 6, 2018

Just wanted to add my +1 -- the inability to use Choosy and Epichrome apps together is a bummer for my workflow, and I'd love to get it back up and running.

EDIT: one more piece of info -- it looks like whatever is breaking Choosy/Epichrome is also breaking "exclude this {epichrome-created} app" functionalities. For example: I use (3) epichrome apps for work. I use the clipboard manager Paste, which lets me exclude apps from being recorded -- so I have blocked (1) of the (3) apps from being recorded.

That block is no longer in effect, due to whatever is keeping the OS from recognizing the Epichrome apps.

@75th
Copy link

75th commented Jan 15, 2019

I can't assign Keyboard Maestro macros to only Epichrome apps; the macros only work if they are not limited by application. Sounds like the same issue.

@voltaireodactyl
Copy link

Just checking if there's been any update on this? The only working replacement I've found is Coherence, but it DOES work.

@75th
Copy link

75th commented Feb 4, 2019

Yeah, Coherence works in this regard, but isn't as good as Epichrome before this breakage. You can't have bookmarks, you can't make external links open in the main Chrome browser, etc. I also really hope we can get a fix for this, and that the Chrome security changes don't leave us stuck with this behavior forever.

@dmarmor
Copy link
Owner

dmarmor commented Mar 19, 2019

Hey @zzamboni (and others), can you tell me if the 2.2.4 update helped with this at all? I'm hoping that codesigning the apps might've made a difference. If it's still broken under 2.2.4, let me know and I'll see if I can reproduce it on my system. Thanks!

@dmarmor dmarmor added the waiting on info waiting for more info from the community label Mar 19, 2019
@75th
Copy link

75th commented Mar 20, 2019

No improvement here. Keyboard Maestro macro groups limited to either Google Chrome or my Epichrome app do not work in the Epichrome app; only global ones do. Macro groups limited to a Coherence app do work correctly.

I have a global macro that runs an AppleScript script that analyzes all windows of the frontmost application. In a Coherence app, it reports the app name as "Gmail" (or whatever the Coherence app is named) and has an entry for the main window as an AXStandardWindow. In an Epichrome app, it reports the app name as "Google Chrome", shows all the actual Chrome windows, but doesn't have an entry for the main Epichrome app window at all. Here's that script:

AppleScript

----------------------------------------------------------------
# Auth: Christopher Stone
# dCre: 2018/12/04 16:33
# dMod: 2018/12/05 13:16
# Appl: System Events
# Task: Report Properties of all Windows of the Frontmost Application
# Libs: None
# Osax: None
# Tags: @Applescript, @Script, @ASObjC, @System_Events, @Report, @Properties,@Windows, @Frontmost, @Application
----------------------------------------------------------------
use AppleScript version "2.4"
use framework "Foundation"
use scripting additions
----------------------------------------------------------------
set shCMD to "#!/usr/bin/env bash

read -r -d '' asCmdStr <<'EOF'
	set tempList to {}

	tell application \"System Events\"

		# set theApp to first application process whose name is \"TextExpander\"
		set theApp to first application process whose frontmost is true

		tell theApp to set winProps to properties of windows
	
		repeat with i in winProps
			set end of tempList to contents of i
			set end of tempList to linefeed
		end repeat
	
		return tempList
	
	end tell
EOF

osascript -e \"$asCmdStr\"
"

tell application "System Events"
	set appName to name of (get first process whose frontmost is true)
end tell

set collatorList to {}

set shellScriptResult to do shell script shCMD
set winRecList to its cngStr:"(?m)^,\\h+" intoString:"" inString:shellScriptResult
set winRecList to its cngStr:"\\A\\s+|\\s+\\Z" intoString:"" inString:winRecList
set winRecList to paragraphs of winRecList

set _pad to "0000000000"
set _sep to "-------------------------------------------------------------------------------------------"
set _cntr to 0
set padLength to (length of (characters of (length of winRecList as text)))
if padLength = 1 then set padLength to 2

repeat with i in winRecList
	set _cntr to _cntr + 1
	set paddedCntr to text -1 thru -padLength of (_pad & _cntr as text)
	set tempStr to contents of i
	set tempStr to (its cngStr:", (?=[[:alpha:]])" intoString:linefeed inString:i)
	set tempStr to (its cngStr:",\\s+\\Z" intoString:"" inString:tempStr)
	set tempStr to (its cngStr:"" intoString:"" inString:tempStr)
	set tempStr to (its cngStr:"(?m)^entire contents:\\R" intoString:"" inString:tempStr)
	set tempStr to (its cngStr:"(?m)^([^:]+):" intoString:("$1" & tab & ":" & tab) inString:tempStr)
	set tempStr to (its cngStr:"missing value" intoString:"zzzz$0" inString:tempStr)
	set tempStr to (its cngStr:"\\R" intoString:linefeed inString:tempStr)
	
	set tempStr to (its cngStr:"(?m-s)^name(?=\\h)" intoString:("Window " & paddedCntr) inString:tempStr)
	
	set shCMD to "echo " & quoted form of tempStr & " | sort -f --field-separator=$'\\t' -k3 | column -t -s$'\\t'"
	set tempStr to do shell script shCMD without altering line endings
	set tempStr to (its cngStr:"zzzzmissing value" intoString:"missing value" inString:tempStr)
	
	set windowName to (its reMatch:"(?m-s)^Window.+" inText:tempStr)
	
	if length of windowName = 1 then
		set windowName to item 1 of windowName
	else
		error "reMatch handler failed!"
	end if
	
	set tempStr to (its cngStr:"(?m)^Window.+?$\\R" intoString:"" inString:tempStr)
	set tempStr to _sep & linefeed & windowName & linefeed & _sep & linefeed & linefeed & tempStr
	
	set end of collatorList to tempStr
	
end repeat

set AppleScript's text item delimiters to linefeed
set collatorList to collatorList as text
set collatorList to _sep & linefeed & linefeed & appName & space & "-- Window Properties Report -- " & paddedCntr & " Windows Listed" & linefeed & linefeed & collatorList & linefeed

return collatorList

----------------------------------------------------------------
--» HANDLERS
----------------------------------------------------------------
on cngStr:findString intoString:replaceString inString:dataString
	set anNSString to current application's NSString's stringWithString:dataString
	set dataString to (anNSString's stringByReplacingOccurrencesOfString:findString withString:replaceString ¬
		options:(current application's NSRegularExpressionSearch) range:{0, length of dataString}) as text
end cngStr:intoString:inString:
----------------------------------------------------------------
on reMatch:findPattern inText:theText
	set theNSString to current application's NSString's stringWithString:theText
	set theOptions to ((current application's NSRegularExpressionDotMatchesLineSeparators) as integer) + ((current application's NSRegularExpressionAnchorsMatchLines) as integer)
	set theRegEx to current application's NSRegularExpression's regularExpressionWithPattern:findPattern options:theOptions |error|:(missing value)
	set theFinds to theRegEx's matchesInString:theNSString options:0 range:{location:0, |length|:theNSString's |length|()}
	set theFinds to theFinds as list -- so we can loop through
	set theResult to {} -- we will add to this
	
	repeat with i from 1 to count of items of theFinds
		set theRange to (item i of theFinds)'s range()
		set end of theResult to (theNSString's substringWithRange:theRange) as string
	end repeat
	
	return theResult
	
end reMatch:inText:
----------------------------------------------------------------

@75th
Copy link

75th commented Mar 20, 2019

Looking at the other similar thread to this one, someone said upgrading from El Capitan to Mojave fixed their issues; I myself am on High Sierra.

@zzamboni
Copy link
Author

zzamboni commented Mar 21, 2019

@dmarmor Unfortunately I still see the same behavior, even with apps that were newly created using Epichrome 2.2.4. In case it makes any difference, I am on Mojave (macOS 10.14.1).

I'd be happy to provide additional info or testing if it would help.

@talleux
Copy link

talleux commented Mar 21, 2019

Looking at the other similar thread to this one, someone said upgrading from El Capitan to Mojave fixed their issues; I myself am on High Sierra.

I case you mean my comment here: #174 (comment)
The update from El Capitan to Mojave actually fixed my Choosy not working.
The update 2.2.4 of Epichrome solved #174
I'm not aware of other issues on Epichrome that were fixed by the update to Mojave.

@januz
Copy link

januz commented Apr 1, 2019

I can also confirm that version 2.2.4 does not fix the issue (I'm on High Sierra).

@ccstone
Copy link

ccstone commented Jul 2, 2019

Hey Folks,

It appears that Epichrome 2.2.4 apps are properly seen by Keyboard Maestro.

(2019/07/02 -- Keyboard Maestro 8.2.4 on macOS 10.12.6)

There's a unique bundle-id like "org.epichrome.app.YouTube", and KM appears to see it alright.

(Although I've only tested with 1 Epichrome app running.)

However – AppleScript support is quite broken still (on macOS 10.12.6 using the latest Chrome).

tell application "System Events"
   tell (processes whose background only is false)
      bundle identifier
   end tell
end tell

Result (as I would expect):

{
   "com.apple.finder", 
   "com.apple.Terminal", 
   "com.barebones.bbedit", 
   "com.brave.Browser", 
   "com.latenightsw.ScriptDebugger5", 
   "com.stairways.keyboardmaestro.editor", 
   "com.apple.mail", 
   "org.epichrome.app.YouTube"
}
tell application "System Events"
   tell (processes whose background only is false)
      name
   end tell
end tell

Result (not what I would expect):

{
   "Finder", 
   "Terminal", 
   "BBEdit", 
   "Brave Browser", 
   "Script Debugger", 
   "Keyboard Maestro", 
   "Mail", 
   "Google Chrome" «----
}
tell application id "org.epichrome.app.YouTube"
   name of windows
end tell

This is a complete failure, and attempts to open the Epichrome YouTube app's sdef (scripting dictionary) in Script Debugger 5, Script Debugger 7, and the Apple Script Editor causes those apps to hang.

This all worked when I tested the system in August of 2018...

What happened?

--
Best Regards,
Christopher Stone

@bradbatt
Copy link

bradbatt commented Jul 3, 2019

I agree with Christopher … this is a major breaking change.

When you look at the Info.plist for an epichrome app it shows correctly. For example, I have an epichrome for ZenDesk and the info.plist shows the following…

<key>CFBundleIdentifier</key>
<string>org.epichrome.app.ZenDesk</string>

If you run the mdls command (mdls ZenDesk.app | grep bundle) it also shows the correct info.

However, when you use AppleScript (osascript -e 'id of app "ZenDesk"') it shows com.google.Chrome

Is this maybe an AppleScript issue? Or something that has changed in Mojave?

@bradbatt
Copy link

bradbatt commented Jul 3, 2019

I use Keyboard Maestro to show and hide SSBs quickly and this bug breaks that functionality completely. Here's a workaround I came up with today that might be useful to anyone else running into the same problems.

I just put this in a "ssb-showhide.sh" script and run it within KM using the name of the SSB app as the parameter (i.e. "~/scripts/ssb-showhide.sh ZenDesk")

It's not as straight-forward as simply using KM to activate or hide, but it works. If the application is not running it will launch it (obviously you need to change the path to where your SSB apps are located).

If running it will bring to the front. If already the frontmost app, it will hide it.

#!/bin/bash
ps_out=`ps -ef | grep $1 | grep -v 'grep' | grep -v $0`
result=$(echo $ps_out | grep "$1")
if [[ "$result" != "" ]];then
	osascript -e "if frontmost of application \"$1\" is false then
			tell application \"System Events\" to tell process \"$1\" to set frontmost to true
		else
			tell application \"System Events\" to tell process \"$1\" to set visible to false
		end if"
else
    ~/Applications/SSB/$1.app/Contents/MacOS/Epichrome > /dev/null &
fi

image

@matthewfallshaw
Copy link

I'm seeing almost the same as everyone else, but both Applescript name and bundle identifier show as Chrome, and only displayed name shows as the name of the Epichrome app.
If I launch (for example) my Asana Epichrome app when it's closed (or any other Epichrome app; via Quicksilver.app or via double-clicking in Finder) it opens. If I launch it while it's open (which should focus it, and used to focus it) I see (in the Dock) an Asana app icon appear beside the existing app icon, then disappear, then another one appear then disappear; the Asana app does not get focus. If I follow a link in another app that should open the appropriate Epichrome app (via Hammerspoon, which I'm using to do what others might use Choosy to do (hi @zzamboni, thanks for all of your excellent work on Hammerspoon!)), the same thing happens and the link doesn't open anywhere.
All of this used to work most of the time, except that occasionally I would see the same launch behavior (I didn't check bundleIDs); when that happened closing my Epichrome apps and re-opening them would resolve the problem (I think it happened when the Chrome instance updated itself).

tell application "System Events"
	repeat with pp in (processes whose background only is false)
		try
			tell pp
				set dn to displayed name as text
				set n to name as text
				set bi to bundle identifier as string
				log {dn, n, bi}
			end tell
		end try
	end repeat
end tell

(*Google Chrome, Google Chrome, com.google.Chrome*)        ← good
(*Skype, Skype, com.skype.skype*)
(*Messages, Messages, com.apple.iChat*)
(*Finder, Finder, com.apple.finder*)
(*Asana, Google Chrome, com.google.Chrome*)                ← bad (Epichrome)
…
(*Google Calendar, Google Chrome, com.google.Chrome*)      ← bad (Epichrome)
(*Script Editor, Script Editor, com.apple.ScriptEditor2*)

Epichrome version 2.2.4 (confirmed via Get Info on each app).
"Automatically update Chrome for all users" is not enabled and the directory /Library/Google/GoogleSoftwareUpdate is not present on my system.

@zzamboni
Copy link
Author

@matthewfallshaw I see the same behavior with my SSBs triggered from Hammerspoon (thanks for the nice comments! Glad you've found my stuff useful 😄) - I hadn't noticed the "ghost icons" because I have the dock hidden most of the time, but I have noticed I often need to quit and restart (or just quit and let them get started automatically by Hammerspoon) the SSB to have links open in them.

@dmarmor
Copy link
Owner

dmarmor commented Sep 21, 2019

Hi all, I'm also a Keyboard Maestro and Applescript user and have had similar problems with Epichrome apps. Unfortunately, there may not be a really good fix for this, as the way macOS and Chrome security is now, I cannot make any changes to the underlying Chrome engine that Epichrome apps rely on, which means the bundle ID will always be Chrome.

I'll put this on my to-do list, though, and will see if I can find a workaround that will allow Applescript to properly address Epichrome apps.

@dmarmor dmarmor added pending working on this for an upcoming release and removed waiting on info waiting for more info from the community labels Sep 21, 2019
@dmarmor
Copy link
Owner

dmarmor commented Dec 2, 2019

Hi all,

I'm working on a major update that I believe will solve this issue (as well as many other long-standing problems). With my work schedule, it may take a while, but I'll let you know when it's ready for testing. Thanks for your patience!

One more thing:

<shameless_plug>

I've set up a Patreon. If you find Epichrome useful and would like to help support its continued development, I've love it if you considered joining. Your membership would help cover the costs and time I put into the project. Membership is per-release, so you'd only be charged when I put out a new version with significant work in it.

</shameless_plug>

@dmarmor
Copy link
Owner

dmarmor commented Dec 21, 2019

Hi @zzamboni,

I've tested the osascript example you opened this issue with and can tell you it will be working in the next version. Still quite a bit of work to do before it's ready to go to beta, but that example is already working in my internal build.

Cheers!

@zzamboni
Copy link
Author

@dmarmor great news! I look forward to checking it out when available.

Cheers!

@zzamboni
Copy link
Author

zzamboni commented May 6, 2020

@dmarmor I finally signed up for your Patreon, and I'm very happy that AppleScript now works with both styles of browser! (I'm testing with b10)

One question: I noticed that Chrome-based apps initially have their own application ID, but it changes back to "com.google.Chrome" after the first invocation. Is this expected? (appid is a short script I have for printing the application ID)

─> appid Netflix.app     # right after creation
org.epichrome.app.Netflix
─> appid Netflix.app     # after first launch
com.google.Chrome

Update: the above seems to be an artifact of my script, which uses AppleScript's id of app to get the ID. I don't know why this reports com.google.Chrome after first execution, but I can confirm that the ID in the app's Info.plist has not changed, and it still responds to events sent to it using its original app ID.

Thanks for all your work!

@dmarmor
Copy link
Owner

dmarmor commented May 6, 2020

Good to hear that Applescript is now working properly. The built-in and external engines do function differently with regard to app ID, and it can be confusing until you understand the engine architecture of Epichrome.

Basically, the app you create with Epichrome is a small wrapper that launches an engine (these engines live in the EpichromeEngines.noindex subfolder where Epichrome.app is installed). If you're using the external Chrome engine, then the engine itself will have the ID com.google.Chrome. And it would be possible for the appid command to get confused, as the engine app has the same name as the main app (probably the better way to invoke appid would be with a full path).

When using Applescript with Epichrome, in general you actually will probably want to address the engine app and not the main app. When the engine is not running, it is replaced with a "placeholder" that will properly launch the main engine, so you can use Applescript to launch directly from the engine. And addressing the engine would be the only way to, for instance, hide a running Epichrome app. But again, you would not want to address it by ID if it's an external Chrome engine, as the ID would be the same as the real Chrome. Best to address it by full path.

This is where the built-in engine has an advantage. It has its own ID, related to the app ID. If the app ID is org.epichrome.app.X, then the engine will have ID org.epichrome.eng.X, and you can use that to easily address it in Applescript.

I hope that helps! Sorry it's so confusing, but a lot of hoops have to be jumped through to get these apps to work under Catalina...

@dmarmor
Copy link
Owner

dmarmor commented May 13, 2020

Closing this for now, as I believe Applescript is working as well as possible with 2.3.0. Ready as always to reopen if more problems crop up.

@dmarmor dmarmor closed this as completed May 13, 2020
@dmarmor dmarmor removed the pending working on this for an upcoming release label May 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants