Skip to content

fix(ego-windows-host): keep new tabs in the requesting space; reject failed browser spawns - #67

Open
zhuran24 wants to merge 2 commits into
opencue:mainfrom
zhuran24:fix/windows-host-tab-space-spawn-error
Open

zhuran24 wants to merge 2 commits into
opencue:mainfrom
zhuran24:fix/windows-host-tab-space-spawn-error

Conversation

@zhuran24

Copy link
Copy Markdown

Summary

Two independent defects in ego-windows-host, one commit each:

  1. A tab created through the bridge was filed under whichever task space was selected when the reply arrived, not the space that asked for it.
  2. ensureBrowser() crashed the process with an unhandled 'error' event when the browser executable could not be spawned, instead of rejecting.

Related issue

None: issues are disabled on this repository.

Changes

1. New tabs are filed under the space that created them (src/ego-bridge.ts)

createTab() and a raw Target.createTarget sent through sendCDPMessage() both recorded the new targetId with registry.trackTarget(id) and registry.setActive(id) when the reply came back. Both default to registry.current(). If the runtime switched task space while the request was in flight, the tab was added to, and made active in, the newly selected space.

createTab() now files the tab under the space it read before sending the request. For a raw Target.createTarget, the bridge keeps the sending space next to the request id and files the reply under that space. If that space was removed in the meantime, the registry ignores the tab instead of moving it into another space.

2. ensureBrowser() rejects when the browser fails to spawn (src/chrome-launcher.ts)

No 'error' listener was attached to the spawned child. A browser path that does not exist or cannot be executed made Node emit an unhandled 'error' event, and the process exited with a stack trace. ensureBrowser() now listens for that error, stops polling for the DevTools endpoint, and rejects with it. A later error is still handled after the polling loop ends.

Reproduction: call ensureBrowser({ port: 1, userDataDir, browserPath: () => "/nonexistent/msedge.exe", timeoutMs: 3000 }) inside a try/catch. On main, the catch never runs:

node:events:505
    throw er; // Unhandled 'error' event
Error: spawn /nonexistent/msedge.exe ENOENT

On this branch, ensureBrowser() rejects with spawn /nonexistent/msedge.exe ENOENT about 20 ms after the call.

Verification

Run from package/ego-windows-host after building package/ego-browser, on Linux, as the workflow's ubuntu-latest leg does.

Check main This branch
npm test (build, typecheck, tests) 57 passed 62 passed
The 5 new tests against main's source 5 fail 5 pass
prettier --check on the changed files n/a clean

The new tests use the existing fakes, so nothing here needs a real browser. They have not been run on a Windows machine; the windows-latest leg of the Windows Host workflow covers that.

Impact

No public API change. Tabs stay in the space that created them across a space switch, and a browser that cannot be started is reported as an error instead of ending the process.

🤖 Generated with Claude Code

zhuran24 and others added 2 commits October 21, 2026 02:24
createTab() and a raw Target.createTarget sent through the bridge both
recorded the new targetId in registry.current() when the reply arrived.
If the runtime switched task space while the request was in flight, the
tab was filed under, and made active in, the space selected at reply
time. Remember the requesting space and file the tab there; when that
space has been removed meanwhile, the tab is not moved into another one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…to spawn

ensureBrowser() attached no 'error' listener to the child it spawns. A
browser path that does not exist or cannot be executed made Node emit an
unhandled 'error' event (ENOENT or EACCES) and the process exited with a
stack trace instead of ensureBrowser() rejecting. Listen for the error,
end the readiness polling with it, and keep a late error from becoming an
unhandled rejection.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant