Epichrome apps don't respond to "open URL" events

[zzamboni]

I've been having the issue that an epichrome app responds well to "open URL" events, e.g. as issued through the open command or Hammerspoon, only when the application is not running. For example, if my "Wiki" app is not running, the following works well, starting the application and opening the given URL:

open -b org.epichrome.app.Wiki <url>

However, once the application is running, the same command does not activate it, nor open the URL.

I know Epichrome 2.3.0 is in development and I'm looking forward to the future versions, just wanted to mention this as I have not seen it in other issues.

Thanks for all your work on Epichrome!

[ldub]

EDIT: I joined Dave's Patreon and downloaded the newest beta, which fixes this issue. Original comment below:

Hi @zzamboni. I have this same issue and some more context. This was not happening with epichrome until I updated to macOS Catalina. If you open Console.app and search for Wiki you should find something like the following:

default	22:05:11.053699-0700	open	Received configuration update from daemon (initial)
default	22:05:11.058439-0700	open	Opening URL <private> with application <private>
default	22:05:11.066200-0700	open	_LSLaunch('<private>')
default	22:05:11.068562-0700	open	LAUNCHING:0x0-0x1acbaca Wiki foreground=1 bringForward=1 seed=10853 userActivityCount=0
error	22:05:11.069272-0700	open	LaunchedApplication: failed with error -13052 (null){ "ApplicationType"="Foreground", "BundleIdentifierLowerCase"="org.epichrome.app.Wiki", "CFBundleExecutablePath"="/Applications/Wiki.app/Contents/MacOS/Epichrome", "CFBundleExecutablePathDeviceID"=16777221, "CFBundleExecutablePathINode"=1576897, "CFBundleIdentifier"="org.epichrome.app.Wiki", "CFBundleName"="Wiki", "CFBundlePackageType"="APPL", "LSASN"=ASN:0x0-0x1acbaca:, "LSBundlePath"="/Applications/Wiki.app", "LSBundlePathDeviceID"=16777221, "LSBundlePathINode"=1576857, "LSDisplayName"="Wiki", "LSExecutableFormat"="LSExecutable#!Format", "LSLaunchDLabel"="org.epichrome.app.Wiki.29968", "LSLaunchedByLaunchServices"=true, "LSLaunchedInQuarantine"=true, "LSLaunchedWithLaunchD"=true, "LSLaunchEventRecordTime"=527778410420509, "LSLaunchTime"=now-ish 2020/03/20 22:05:11, "LSWantsToComeForwardAtRegistrationTimeKey"=true, "pid"=25506 }
default	22:05:11.069835-0700	open	OSStatus _LSLaunch(LSContext *, FSNode *, LSLaunchFlags, void *, CFArrayRef, const AppleEvent *, const AEDescList *, CFArrayRef, CFDictionaryRef, LSBundleID, const audit_token_t *, const _LSOpen2Options *, ProcessSerialNumber *, Boolean *, NSError **): launching '<private>' result=0

The interesting part of this is error -13052. Other apps are facing this issue too:

geany/geany-osx#13
https://bugs.launchpad.net/calibre/+bug/1855515
https://emacs.stackexchange.com/questions/53248/finder-of-macos-catalina-cannot-open-a-file-with-emacs/54383#54383

It appears that something changed with opening apps using shell scripts in Catalina. I would really love to see this get fixed as it would allow me to use epichrome with Choosy or https://github.com/johnste/finicky which used to be a valuable part of my workflow. @dmarmor I just found out about your Patreon and the betas of 2.3.0 and instantly subscribed. I use epichrome apps every day :)

[dmarmor]

Yes! Thanks @zzamboni & @ldub. This is fixed in 2.3.0. I'll post again here when it's released.

[zzamboni]

@dmarmor I finally signed up for your Patreon, and can confirm that this is fixed in 2.3.0b10 - thanks! (Note: it seems to still be broken for the Chrome-based SSBs, but works perfectly with Brave)

[dmarmor]

Good to hear there's progress. But can you let me know what's happening with Chrome-based apps? In my tests those have been working as well. How are you trying to send the open URL event?

[dmarmor]

Hey, @zzamboni, are you still having problems with Chrome-based apps? Can you send me some more info on how you're testing it and the results you're seeing? Thanks!

[gregschroeder]

This inability to open URLs (via Finicky) into the proper app if already open was the primary bug that drove me to try 2.3.x, but I run into showstopper problems with both Brave (no session state, permissions) and Chrome (stomps on com.google.chrome URL handler).

So I reverted to 2.2.4 and did some experimenting, and found this workaround: use AppleScript to set the location in the SSB. This seems to correctly open the given URL in a new tab if already running, and starts the app if not.

I use Finicky, which requires a bundle ID, so one way to complete this hack is:

1. Create /tmp/script to do the AppleScript call (replace MYSSB as appropriate)

#!/bin/bash
osascript -e "tell application \"MYSSB\" to open location \"$1\""

2. Use Platypus to create a dummy opener app with a bundle ID, and install this within the SSB

platypus -y -o None -R -I org.epichrome.app.MYSSB_opener -U 'http|https' /tmp/script /Applications/SSB/MYSSB.app/Contents/MacOS/org.epichrome.app.MYSSB_opener

3. Now you can use org.epichrome.app.MYSSB_opener as the bundle ID to open a URL, which will immediately delegate to the Epichrome SSB

open -b org.epichrome.app.MYSSB_opener 'https://yahoo.com'

or configure Finicky to call it, etc.

Can this open location technique via osascript be added to the Epichrome script itself, such that I don't need to write these wrappers for each one?

[dmarmor]

This was pretty funny to me, because if I understand what you describe properly, you basically recreated Epichrome 2.3.x with 2.2.4. 2.3.x Epichrome apps actually use Platypus as the launch app specifically so they can take advantage of picking up launch documents as you've done here.

So basically, my recommendation would be to try using a 2.3.x app in the way you describe at the end. You should be able to issue:

open -b org.epichrome.app.MYSSB 'https://yahoo.com'

to your app (running or not) and have it launch that URL in the engine. If you can't then I will need to look at that as an issue, but a lot of the design work on 2.3.x was specifically to get that very behavior working through Platypus.

In general, you shouldn't ever try to address a Chrome-engine app by ID, as it will inevitably confuse the system with the real Chrome. In most applications you can address apps by full path instead, and this would be the better way to handle it. (I believe someone added this ability to Finicky in a pull or something, but I can't find the reference right now.)

[zzamboni]

@dmarmor my apologies, I just now noticed that I never replied to your latest question above!

What I did in the end was switching all my Epichrome SSBs to the Brave engine, and I've been happy ever since. I would be happy to do another round of testing with Chrome-based apps if you are interested.

Thanks again, and all the best.

[dmarmor]

Hi @zzamboni, thanks for the reply. Glad to hear the Brave engine has been working well for you. Probably best to wait for Epichrome 2.4 before doing more testing on Chrome-engine apps, as the engine architecture is significantly different in 2.4 and hopefully will mitigate some of these problems (though Chrome-engine apps will still always be confused with the real Chrome if addressed by ID--there's just no way around them having the same ID). Cheers!