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
Comments
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: AppleScript
|
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. |
I case you mean my comment here: #174 (comment) |
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):
tell application "System Events"
tell (processes whose background only is false)
name
end tell
end tell Result (not what I would expect):
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? -- |
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…
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.
|
I'm seeing almost the same as everyone else, but both Applescript 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 →
Epichrome version 2.2.4 (confirmed via Get Info on each app). |
@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: <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> |
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)
Update: the above seems to be an artifact of my script, which uses AppleScript's 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.
The text was updated successfully, but these errors were encountered: