Closed zzamboni closed 4 years ago
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.
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.
Just checking if there's been any update on this? The only working replacement I've found is Coherence, but it DOES work.
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.
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!
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:
---------------------------------------------------------------- # 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: ----------------------------------------------------------------
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.
@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.
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: https://github.com/dmarmor/epichrome/issues/174#issuecomment-473576981 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.
I can also confirm that version 2.2.4 does not fix the issue (I'm on High Sierra).
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
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?
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
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.
@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.
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.
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:
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!
@dmarmor great news! I look forward to checking it out when available.
Cheers!
@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!
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...
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.
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):
I've also tried specifying the ChromeEngine app inside the application bundle, but I get the same:
Is it still possible to make this work? I found this feature extremely useful.