"Source Application" rule Choosy not working for Epichrome apps

[santip]

When using rules in Choosy to pick a target browser based on source app, if the source app in the rule is an Epichrome it will not work.

I tried both the app on /Applications and the app inside /Applications/Epichrome/EpichromeEngines.noindex/<username>/<appname> but neither is recognized by Choosy
I also tried picking /Applications/Google Chrome and it doesn't help either to recognize an Epichrome app based on chrome engine.

The rule type does work correctly for other (non-Epichrome) apps such as /Applications/Slack.app

[talleux]

@santip i use Choosy and Epichrome very intensively. I have no problems at all. I never had to decide which source to use. My workflow:

• While creating a new Epichrome i choose "register as browser). I don't know if this setting can be edited afterwards (@dmarmor ?).
• I choose this new app in choosy from the list of browser while editing rules.

Does this help? Do you need more infos?

[dmarmor]

Hi @santip, I haven't used Choosy myself, but my guess is this may not work because the app itself is not the source of the outgoing link. In the same way that I'd guess you couldn't use Chrome itself as a source app, because Chrome doesn't send links outside itself normally.

What happens in an Epichrome app is that when the Helper extension decides a link should be sent to the default browser (in this case Choosy), it communicates the URL to a native message host, which is a little executable that runs in the background as long as the extension is active. Then that executable launches the URL, and Choosy picks it up from there. So Choosy wouldn't see the URL as being sent by the Epichrome app.

Out of curiosity, have you used the Choosy extension in any of your browsers? If you send a link to Choosy using that extension, does Choosy properly realize which browser it came from as the source app in its rules? If so, then it may be doing some magic with its native message host that could be figured out...

[santip]

Hi @dmarmor, I actually tried the Choosy extension both in Chrome and Brave engines but it didn't seem to have any effects.

I even tried extensions that would rewrite urls to prepend the Choosy protocol and a custom tag to identify the source in choosy rules. But this had no effect on outgoing links since the rewrite happens when chrome actually performs the network request.

However, if the Epichrome extension could be configured to rewrite outgoing links before communicating it to the native message host, then it would be possible to accomplish my intended multi-browser setup successfully.

Just to clarify the use case, I have two separate chrome-based instances for personal and work browsing. I use choosy to properly route specific links to each.

Now I have an issue with Gmail notifications coming from Chrome that will trigger tabs opening on every running chrome instance. I wanted to overcome this by adding 2 more dedicated browser for each Gmail account (work and personal) using the brave engine (shouldn't have the notification problem and is also desirable), but I really need to route EVERY link from each Gmail app to the correct chrome instance (work / personal) and I can't achieve that with Choosy right now.

[santip]

I need the two primary browsers to be chrome-based to use Google Account syncing and for some work related needs.

[dmarmor]

I'm not sure I follow all the intricacies of your setup, but it might be plausible to do some kind of rewriting on URLs (just so you understand, this would be a ways down the road--I have a very full list of high-priority work to do on Epichrome right now and not a lot of time to work on it). Can you give me some more info on what this rewriting would look like to be useful to you?

[santip]

Essentially an option to provide a regex based replacement of urls before they are posted to the OS, could be as an additional option in the Epichrome extension that I assume deals with deciding whether to navigate inside the same browser or push it to the native message.
If the extension code is open source and not super complex, I could take a look and see what it would take to create a PR

Thanks,
Santiago

[dmarmor]

Gotcha. Yeah, that would be a cool feature, and I'd certainly welcome your work on it if you have the time and expertise. The extension is indeed open source and part of this repo. You can find it in the runtime directory. I actually have a beta version underway that's not in the repo yet, but I should be able to integrate anything you come up with...

Thanks!

[edubecks]

@santip I have the same problem too. My workaround was to create rules in Choosy

Source Application -> is not -> Google Chrome (or Slack)

and other apps where you don't use the google account # 1