emrun quits immediately

[ypujante]

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 6.0.6 (ce75e06884093bcefb86a6b8fd56a5d62a4cc245)
clang version 24.0.0git (https:/github.com/llvm/llvm-project ff6d537b14d737719d6377789784d04ff9565f65)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /usr/local/emsdk/upstream/bin

Failing command line in full:

emrun --verbose --browser firefox index.html

Full link command and output with -v appended:

Web server root directory: /Volumes/Vault/deployment/build/emscripten-glfw/Debug
Starting web server: http://0.0.0.0:6931/
Starting browser: /Applications/Firefox.app/Contents/MacOS/firefox -url http://localhost:6931/index.html
/Applications/Firefox.app/Contents/MacOS/firefox
Searching for processes by full path name "/Applications/Firefox.app/Contents/MacOS/firefox".. found 1 entries
Before spawning web browser, found a running firefox browser process id: 917
Launched browser process with pid=12404
Now listening at http://0.0.0.0:6931/
Entering web server loop.
First navigation occurred. Identifying currently running browser processes
Searching for processes by full path name "/Applications/Firefox.app/Contents/MacOS/firefox".. found 2 entries
Detected running browser process id: 917, existed already at emrun startup? True
Detected running browser process id: 12404, existed already at emrun startup? False
Shutting down because browser is no longer alive
Browser process has shut down, quitting web server.
Web server loop done.
Closed web server.
emrun quitting with process exit code None

I am in the process of testing my changes to the latest version of emscripten-glfw (support for GLFW 3.5.1) and I run the exact same command I use to run: emrun --verbose --browser firefox index.html

Before, this was opening firefox and displaying index.html which is a static page that links to all the demos, then I could just click to every demo to see it. But now, it displays the page and quits as shown in the verbose output, stating "browser is no longer alive" which is absolutely not true (I did not quit the browser). If I start with --no-browser instead then it stays alive and doesn't quit.

I am not sure if this is the expected behavior, but it was not working that way before. Looking at the Changelog I am not seeing any obvious entry explaining this change (if it is an intentional change)

[sbc100]

Can you confirm the version you were using when this last worked as expected for you?

[ypujante]

I do not exactly remember. My best guess would be the last time I released emscripten-glfw so around March of 2026.

I just found something a bit odd:

• if I do emrun --browser=firefox ./index.html then I see the problem I described
• if instead, I call the python script directly, it behaves the way I am expecting and remains opened:

> python3 /usr/local/emsdk/upstream/emscripten/emrun.py --verbose --browser=firefox ./index.html
Web server root directory: /Volumes/Vault/deployment/build/emscripten-glfw/Debug/test/unit
Starting web server: http://0.0.0.0:6931/
Starting browser: /Applications/Firefox.app/Contents/MacOS/firefox -url http://localhost:6931/index.html
/Applications/Firefox.app/Contents/MacOS/firefox
import psutil failed, unable to detect browser processes
Searching for processes by full path name "/Applications/Firefox.app/Contents/MacOS/firefox".. found 0 entries
Launched browser process with pid=10940
Now listening at http://0.0.0.0:6931/
Entering web server loop.
First navigation occurred. Identifying currently running browser processes
import psutil failed, unable to detect browser processes
Searching for processes by full path name "/Applications/Firefox.app/Contents/MacOS/firefox".. found 0 entries

So it seems that the wrapper script is the culprit?

[sbc100]

Gemini came up with the following explanation for this breakage:

PR #26928 Added support for passing macOS .app root paths (e.g. --browser firefox or --browser Firefox.app):

• Previously, macOS runs without a browser path defaulted to options.browser = 'open', where process search list_processes_by_name('open') returned [] and bypassed process tracking.
• When --browser firefox (or a specific binary path) is passed, browser_exe gets set to /Applications/Firefox.app/Contents/MacOS/firefox, activating detect_browser_processes() (introduced in PR Update emrun to latest version #10046).
• This exposed the race condition in detect_browser_processes() whenever a browser handoff stub process is captured
  in current_browser_processes before it finishes exiting.

[ypujante]

I have literally no idea how to interpret this AI explanation. Does it mean there is a bug? Does it mean the change exposed a bug and fixed it? Or didn't fix it?

Why is it working when invoking the python script directly but not via the shell script?

[sbc100]

Yes, its a bug introduced in #26928