open

Description / can throw even when the default browser is one of the ones this is supposed to support. Root cause The map in is keyed in lowercase: But returns ids with whatever casing the vendor chose. macOS Safari's real bundle id is , and Brave's is on both macOS and Windows (confirmed in 's own windows.js and its test suite). runs against the raw, differently-cased id and fails, and only the value lookup lowercases — too late, since the function has already fallen through to the "not supported" branch. Chrome/Firefox/Edge's real ids happen to already be all-lowercase, so they're unaffected. Only Safari and Brave hit this. Expected behavior / should recognize Safari and Brave as the default browser, matching what the readme documents (" and only supports , , , and "). Fix Lowercase the id once and reuse it for both the check and the lookup: I already have this fixed with a regression test on a branch: https://github.com/otnc/open/tree/fix/default-browser-id-case A week ago I would have opened this as a pull request directly, but pull requests on this repository now seem to be limited to collaborators only, so I'm filing it as an issue instead, with the fix branch above for reference.

Problem On Windows, (without ) can silently fail to open anything, even though it resolves without throwing. This reproduces with a plain call like: This is not specific to any particular runner (npm scripts, , etc.) — it reproduces with a bare invocation that does nothing after the . Root cause On Windows, the actual command is always wrapped in a launcher that runs a base64-encoded script. The comment above the non-fallback resolution path assumes: The launcher (open/xdg-open/PowerShell) exits quickly (~10-30ms) even on success. That assumption holds for macOS and , but not for legacy Windows PowerShell (, which always targets — Windows still isn't defaulting new processes to , so this is the common case, not an edge case). Starting it up (loading the runtime, applying , decoding and parsing the script) routinely takes several hundred ms, well past that ~10-30ms assumption. The non-fallback, non- path only waits for the event before resolving: only means the OS handed back a process handle for — not that it has finished executing the encoded command yet. If the caller does nothing meaningful after (a very common pattern, e.g. a short-lived CLI script), the process can exit right after this resolves. Since the Windows branch never sets on (only the Linux branch does), the still-starting child is not detached from the caller, and can be torn down before it ever gets to run . I confirmed this directly: replacing the -based resolution with one that waits for the launcher's event (what the existing path already does) makes it succeed reliably, taking ~200-900ms depending on system load — consistent with legacy PowerShell startup cost, not with the app itself. Related: #298 (closed as "probably fixed" by 966239c, which added the wait — that made things better but didn't fully close the race on Windows specifically, for the reason above). Also related: #144, #189. Fix Reuse the existing handling (which already waits for the launcher's event before resolving) for the Windows path too, since Windows always goes through this same kind of short-lived launcher process. This does not wait for the opened app to close — only for the (still fast, just not ~10-30ms fast) launcher script that runs in. It's unrelated to , which additionally passes to itself to block until the opened app exits. Testing passes on the changed files. Added a Windows-specific test mirroring the existing test, but asserting the opposite (resolves after close) — gated by , leaving the non-Windows test and behavior untouched. Manually verified against a real launch on Windows 11: without this change, the browser did not open; with it, waits for the launcher and the browser reliably opens. Fixes #298

Hi, I've been using this library successfully for quite some time to open a local file (the "index.html" file containing a Jest coverage report). Unfortunately, since the update to v11, it no longer works. Is this a breaking change (I haven't been able to find the changelog)? Or is it a bug? I am on Windows 10. Thanks.