Improve browser selection and add Helium support - #3
Conversation
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| family: "chromium", | ||
| profileRoots: [path.join(localAppData, "Google", "Chrome", "User Data")], | ||
| nativeManifestRoots: [], | ||
| applicationPaths: windowsApplicationPaths("Google", "Chrome", "Application", "chrome.exe"), |
There was a problem hiding this comment.
When a Windows user runs OpenBrowser setup chrome or OpenBrowser install chrome, the new catalog definition supplies no registryRoots, so the installer writes the native-host manifest without registering it under Chrome's NativeMessagingHosts key. Chrome therefore cannot discover or launch the native host, leaving the extension unable to establish the bridge even though setup reports completion.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 25 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="src/browsers/shared.js">
<violation number="1" location="src/browsers/shared.js:92">
P2: When a wrapper command such as macOS `open -a` starts but cannot find its target application, `launchBrowser` treats it as successful and skips later candidates. Validate the wrapper's result or model wrapper commands separately before returning success.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| } | ||
|
|
||
| child.once("error", () => finish(false)); | ||
| child.once("spawn", () => { |
There was a problem hiding this comment.
P2: When a wrapper command such as macOS open -a starts but cannot find its target application, launchBrowser treats it as successful and skips later candidates. Validate the wrapper's result or model wrapper commands separately before returning success.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At src/browsers/shared.js, line 92:
<comment>When a wrapper command such as macOS `open -a` starts but cannot find its target application, `launchBrowser` treats it as successful and skips later candidates. Validate the wrapper's result or model wrapper commands separately before returning success.</comment>
<file context>
@@ -17,17 +18,88 @@ export function installNativeHost(browser) {
+ }
+
+ child.once("error", () => finish(false));
+ child.once("spawn", () => {
+ child.unref();
+ finish(true);
</file context>
|
Addressed in commit
Local verification passes: 30 tests, both extension builds, WebExtension lint, and package dry-run. |
1 participant
Summary
This PR makes browser selection local, discoverable, and mostly automatic. It adds Helium support, keeps Chrome and Zen support, introduces one shared browser catalog, and updates the CLI/agent skill so daily commands no longer need a hard-coded
--browserflag.Version is bumped to 2.2.0.
Setup after this PR is merged
Each user runs setup once on their own machine. The selection is stored in that user's
~/OpenBrowser/config.json; it is not stored in the repository and does not affect other users.Helium
On macOS, setup will:
~/OpenBrowser/native-host/.net.imput.helium/NativeMessagingHosts/).~/OpenBrowser/extensions/helium/.heliumas the local default browser.Because Chromium browsers do not allow this package to install an unpacked extension directly into a profile, the user then opens Helium's extensions page, enables Developer mode, chooses Load unpacked, and selects the staged path reported by setup. Once the extension is loaded, the bridge is ready.
Chrome
The flow is identical:
Chrome receives its own native-host launcher, browser-specific Windows registry entry/manifest when applicable, staged extension directory, and bridge socket. It reuses the same Chromium extension artifact as Helium. Setting up Chrome and Helium on the same Windows machine no longer overwrites either browser's native-host manifest.
Zen
Zen uses the Firefox-family flow: the bundled XPI is copied to detected Zen profiles and the native-messaging manifest/launcher are installed. Zen must be opened once first so its profile can be discovered. Partial installs are not treated as configured until the native host, manifest, and profile extension are all present.
All Firefox and Chromium artifacts now include PNG extension icons at the standard sizes.
Normal daily usage
After setup, commands are browser-neutral:
The explicit override remains available for multi-browser workflows:
The friendly default command is also available:
Selection behavior
Selection precedence is:
--browser <id>OPENBROWSER_BROWSERA configured default now short-circuits discovery and does not probe unrelated browser bridge sockets on every daily command. If the configured target is incomplete, OpenBrowser falls back to discovery and provides setup guidance. If multiple active, configured, or detected browsers are possible, OpenBrowser reports the choices instead of silently defaulting to Zen.
OpenBrowser browsers --jsonprovides machine-readable status for automation.Review fixes included
OpenBrowser browsers.open -ato exit successfully before trying the next candidate.Implementation details
not detected,installed,configured,ready, andactive).setup,browsers, anduseCLI commands while preserving--browser,install <browser>, andconfig browser.Verification
npm test— 30 tests passed.npm run build— Firefox and Chromium artifacts built successfully.npx web-ext lint --source-dir extensions— no errors, notices, or warnings.npm pack --dry-run— package contents include the new catalog, discovery, Helium adapter, icons, CLI, skill, and version2.2.0.