Fluid v1.4

The current SSB stays focused, however the Window loses focus (the Application is still the foremost application, however).

MacOS 10.13.1. Chrome 61.0.3163.100 64bit. Seems to have started in the last few weeks. Choos Safari or Firefox and those open correctly.

I'd like to have it so that a left click uses the default system browser, and a right click brings up Choosy, or at least Choosy's browser list in the contextual menu. There seems to be no option for this in settings or advanced rules.

I'm not sure if this is possible or not, but just like we have the existing regular expression system plus the Firefox plugin, have the browser plugin send a given URL to Safari (for example) if the loading page matches an expression.

Reason?? I love Firefox but I can't use it with Flash/video sites (like YouTube and Vimeo)... Forget it, it's SLOOW and borderline useless.

I'd love this feature! :) <3

The browser plugins are great for sending windows to a different browser, but for people like me who keep tons of tabs open at once, it'd be awesome if I could send them all to a different browser at once.

I use HipChat's desktop air app for OS X and unfortunately choosy just opens them right up in Chrome :( I saw in a previous release note that you fixed it working for air apps, maybe this one is different?

I have a rule which says "if source application is /Applications/ReadNow.app, use best running browser". However, even if I promote this rule to rule 1, when I open a link from ReadNow, I am asked to select from all running browsers instead of it Just Working and opening the link in Safari.

Choosy works correctly with similar rules referencing other applications. What's going wrong here?

Choosy only recognizes Google Chrome's profile with "Default" or "Profile x" directories.
But a profile directory can be anything if you create it with `profile-directory` parameter.
For example:
```sh
$ open -a "Google Chrome.app" --args --profile-directory="foobar"
```
And I prefer this way because "Profile x" is not semantic.
Please support this case.

The Whatsapp desktop client 0.3.1847 on OS Sierra 10.12.6 seems to ignore any rules completely.

I have a Chrome app for web mail. It would be awesome if I could get Choosy to open links in that Chrome app. But I don't know if Choosy can see them as valid app/browser targets.

I often get URLs in Adium and other places that were pasted from Firefox which leaves them incorrect by html-encoding the URL. This results in "http://foo.com/?bar&amp;baz&quot; rather than "http://foo.com/?bar&baz&quot;

A simple regexp substitution could fix this; allowing a generic external rewrite API would be even better.

As a workaround, I'll see if I can write an app that accepts such URLs, and sends the corrected ones back to Choosy; then I can have Choosy send them to it rather than a 'real' browser…

i updated to Choosy 1.3 and got this:
Could not load Choosy preference pane.
So... wait for update?
Mac OS 10.13.6 (17G65) High Sierra
Thanks

I have a rule set up to open urls to audio file types in QuickTime Player. It'd be great if the Choosy Safari extension could read my rules and intercept these URLs and do the right thing.

I really like Choosy. Just bought it. But I'd like to see it improve in performance. My super powerful MacBook Pro takes about half a second to open a link and display the browser. Without Choosy it happens in immediately. Any ways to achieve that? Kind regards Eric

I am using choosy with fluid and I would like it so when I click on os x's built in facebook notifications, my fluid facebook app opens. I was unable to find a way to achieve this via advanced rules, and even if it is possible, it would be nice if the "source application" rule were just "source" and one was allowed to select things that aren't considered applications (such as os x notifications).
In the meantime though, is there a way to achieve this with the current state of choosy?

Choosy always displays the prompt even when my #1 browser is running. It didn't used to do this but it has been consistently acting this way for a while.

I'm sure this used to work, but it's broken in 0.93: dragging a browser entry just results in it flying back into place. Expected behaviour: the list is reordered.