[vpacher]

Refs obs-rust/obs-studio#2387

What and why

On macOS obs-browser runs CEF on Qt's main loop (ENABLE_BROWSER_QT_LOOP), and obs_browser_initialize() ran BrowserInit() on the calling thread: CefInitialize() makes that thread CEF's UI thread. The first browser source initializes CEF from its create callback, so when obs-websocket created it (CreateInput, on its IO thread), CEF's UI thread was one that never pumps. Only the GPU process started, and no browser source rendered for the rest of the session, also ones recreated in the UI later.

obs_browser_initialize() now runs BrowserInit() on the Qt main thread and waits for it (QMetaObject::invokeMethod(..., Qt::BlockingQueuedConnection)) when it is called from another thread. On the main thread, and without a Qt application, it calls it directly as before. Linux and Windows (their own CEF thread) are unchanged.

RED → GREEN

tests/first_source_off_main_thread.py (new, macOS, local like the other real-CEF tests) starts the built OBS-Studio-Rust.app with a fresh, seeded configuration and obs-websocket on a test port, and requires a browser source with first-source.html (a page that turns green) to render. Scenarios: websocket-first (obs-websocket creates the first source) and collection (the scene collection has it, so OBS creates it on the main thread; the control).

• RED 0a4106f: collection renders, websocket-first stays black for 30 s.
• GREEN bfeba2d: both render, in 3 of 3 runs.
• The branch is on master with Name the macOS helpers after the app (obs-rust/obs-studio#2386) #9 (the helper names): on the Rust brand, browser sources need Name the macOS helpers after the app (obs-rust/obs-studio#2386) #9 to start their helpers at all.
• macOS 26.7.1, Apple Silicon, CEF 7871. The main-thread path (direct call) is the collection scenario; a source added in the UI goes the same way.

AI note: Claude Code (Claude Opus 5.5) wrote the change, the test and this text under the submitter's direction, and ran the tests above on the submitter's machine.

[zackees]

Coordinator review: approved.

• The cause and the fix match: with ENABLE_BROWSER_QT_LOOP, CefInitialize() makes the calling thread CEF's UI thread, so the first source created from obs-websocket's IO thread left CEF on a thread that never pumps. Handing BrowserInit() to the Qt main thread when called from elsewhere, and calling it directly on the main thread or without a QCoreApplication, keeps every existing path the same. Linux and Windows are untouched.
• RED → GREEN in the real app (macOS 26.7.1, CEF 7871): websocket-first was black and now renders 3 of 3 times, and the collection control passes in both. The test refuses to touch an existing config folder, which is the right call for a test that seeds ~/Library/Application Support.

Note (non-blocking): BlockingQueuedConnection deadlocks if the main thread is waiting on the calling thread at that moment, or isn't running its event loop. Today obs_source_create calls create without an OBS-global lock, and obs-websocket's request thread isn't something the UI thread waits on, so I don't see a path. A first browser source created off the main thread during shutdown (after the Qt loop has stopped) would hang, though. A guard like if (QCoreApplication::closingDown()) return false; before the blocking call would cover that.