Description
PR #65 fixed explicit bringToFront() calls during background tab selection and binding, but a cold browser launch still makes Chromium the frontmost macOS application.
This affects the first browser-backed command after the daemon/runtime has stopped. Warm reuse of the same persistent site session behaves correctly.
Related: #66, #65
Steps to Reproduce
Using the current source checkout (v0.3.0, commit 9362750):
-
Stop the daemon and confirm Cloak Chromium is no longer running:
npm run dev -- daemon stop
-
Put Safari in the foreground.
-
Run a browser-backed command in background mode:
npm run dev -- twitter whoami --window background -f json
-
Observe the frontmost macOS application throughout the command.
Actual Behavior
The command succeeds, but Chromium takes focus and remains frontmost.
A live focus monitor sampled the cold run as:
focus_before=Safari
focus_after=Chromium
8 Safari samples
18 Chromium samples
After reactivating Safari and immediately repeating the same command against the warm persistent site:twitter lease, all 13 samples remained Safari.
npm run dev -- doctor was green before testing.
Expected Behavior
With --window background, a cold start may create a visible headed Chromium window, but it should remain behind the currently active application. The behavior should match warm-session reuse: no focus theft.
Default/explicit foreground mode should retain its existing behavior.
Root Cause Evidence
The PR #65 path correctly skips bringToFront() for background selection and binding. The cold-launch path is separate:
getPage() calls getProfileRuntime(profileId) without carrying windowMode into runtime creation.
launchProfileRuntime() launches Cloak with headless: false and humanize: true, but does not consume windowMode or otherwise prevent/undo native application activation.
The remaining failure is therefore at headed profile/runtime launch, not tab selection or binding.
Acceptance Criteria
- A cold browser-backed command with
--window background does not make Chromium frontmost on macOS.
- Warm background commands continue preserving the current foreground application.
- Default and
--window foreground behavior remains unchanged.
- Add the smallest regression coverage for propagation through the cold runtime-launch path.
- Verify live on macOS with another application foreground during both cold and warm runs.
Environment
- webcmd source:
0.3.0 at 9362750
- Node.js:
23.11.0
- macOS:
26.5.2 (25F84)
Description
PR #65 fixed explicit
bringToFront()calls during background tab selection and binding, but a cold browser launch still makes Chromium the frontmost macOS application.This affects the first browser-backed command after the daemon/runtime has stopped. Warm reuse of the same persistent site session behaves correctly.
Related: #66, #65
Steps to Reproduce
Using the current source checkout (
v0.3.0, commit9362750):Stop the daemon and confirm Cloak Chromium is no longer running:
Put Safari in the foreground.
Run a browser-backed command in background mode:
Observe the frontmost macOS application throughout the command.
Actual Behavior
The command succeeds, but Chromium takes focus and remains frontmost.
A live focus monitor sampled the cold run as:
After reactivating Safari and immediately repeating the same command against the warm persistent
site:twitterlease, all 13 samples remained Safari.npm run dev -- doctorwas green before testing.Expected Behavior
With
--window background, a cold start may create a visible headed Chromium window, but it should remain behind the currently active application. The behavior should match warm-session reuse: no focus theft.Default/explicit foreground mode should retain its existing behavior.
Root Cause Evidence
The PR #65 path correctly skips
bringToFront()for background selection and binding. The cold-launch path is separate:getPage()callsgetProfileRuntime(profileId)without carryingwindowModeinto runtime creation.launchProfileRuntime()launches Cloak withheadless: falseandhumanize: true, but does not consumewindowModeor otherwise prevent/undo native application activation.The remaining failure is therefore at headed profile/runtime launch, not tab selection or binding.
Acceptance Criteria
--window backgrounddoes not make Chromium frontmost on macOS.--window foregroundbehavior remains unchanged.Environment
0.3.0at936275023.11.026.5.2(25F84)