Setup
- Finicky 4.4.0-alpha, macOS 15 (Darwin 24.6), Google Chrome with two profiles
- Each profile has its window on its own macOS Space (personal on desktop 2, work on desktop 4); links are usually clicked from a third app on yet another Space (desktop 3)
- Handlers use profiles:
{
match: ["substack.com/*", "*.substack.com/*"],
browser: { name: "Google Chrome", profile: "Business" },
}Problem
The URL always opens as a tab in the correct profile's window — routing works great. But focus doesn't follow the tab. Finicky launches via open -a "Google Chrome" …, which activates Chrome at the app level; macOS then fronts whichever Chrome window lives on the current Space (or the last-used one) — usually the other profile. The user has to hunt across Spaces for the tab that just opened.
Workaround that works (and what it taught us)
I replaced Chrome in the handler with a small AppleScript applet that:
- snapshots
id of active tab of every window in Chrome,
- runs
open -na "Google Chrome" --args --profile-directory=… <url>,
- polls until one window's active tab id changes (or a new window appears) — that's the window that received the tab,
set index of theWin to 1, then via System Events: perform action "AXRaise" of window 1 + set frontmost to true.
This reliably pulls focus across Spaces to the right window. Two pitfalls that cost me iterations, in case they help an implementation:
- Matching the target window by title fails — the new tab often still reports "Untitled" while loading.
- Detecting the change by active-tab URL fails when the same URL is opened twice; tab ids are the reliable signal.
Residual cosmetic quirk of the workaround: the app-level activation still flashes the wrong window for ~a second before AXRaise lands. A native implementation could likely avoid that by raising before/while activating.
Suggestion
An opt-in per-handler flag, e.g. focusWindow: true, that makes the launcher raise the specific window that received the tab when a profile is set. Happy to test a build — and thanks for Finicky, it removed real daily friction for me.
Setup
Problem
The URL always opens as a tab in the correct profile's window — routing works great. But focus doesn't follow the tab. Finicky launches via
open -a "Google Chrome" …, which activates Chrome at the app level; macOS then fronts whichever Chrome window lives on the current Space (or the last-used one) — usually the other profile. The user has to hunt across Spaces for the tab that just opened.Workaround that works (and what it taught us)
I replaced Chrome in the handler with a small AppleScript applet that:
id of active tab of every windowin Chrome,open -na "Google Chrome" --args --profile-directory=… <url>,set index of theWin to 1, then via System Events:perform action "AXRaise" of window 1+set frontmost to true.This reliably pulls focus across Spaces to the right window. Two pitfalls that cost me iterations, in case they help an implementation:
Residual cosmetic quirk of the workaround: the app-level activation still flashes the wrong window for ~a second before AXRaise lands. A native implementation could likely avoid that by raising before/while activating.
Suggestion
An opt-in per-handler flag, e.g.
focusWindow: true, that makes the launcher raise the specific window that received the tab when aprofileis set. Happy to test a build — and thanks for Finicky, it removed real daily friction for me.