Repository navigation
Windowed (non-OSR) browser close never fires onBeforeClose -- hangs indefinitely #3
Description
Summary
TestFrame's default windowed (non-OSR) browser close handshake hangs indefinitely: after the documented 7-step close sequence (windowClosing -> close(false) -> doClose() cancels -> re-dispatch -> close(true) -> doClose() allows -> native window destroyed), CefLifeSpanHandler.onBeforeClose is never invoked, so any test/app blocking on it (e.g. via a CountDownLatch) hangs forever.
Matches upstream chromiumembedded/java-cef#364 ("CefBrowser_N.doClose() unexpectedly closes the host window"), filed by the JCEF/CEF maintainer -- about the same CefBrowser_N.doClose() -> SwingUtilities.invokeLater -> synthetic WINDOW_CLOSING re-dispatch mechanism.
Reproduction
Confirmed reproducible and independent of environment -- identical symptom under two unrelated X setups:
- WSLg's real X server (has its own window manager).
- A from-scratch
Xvfb+icewm+dbus-launchsetup (a real, if virtual, X server + WM).
In both cases: onAfterCreated -> resource load -> terminateTest -> close(false) -> doClose() cancels -> close(true) -> doClose() allows -> Frame.dispose() all fire correctly, then nothing. onBeforeClose/cleanupTest never print. jstack on the hung process shows the main thread parked in CountDownLatch.await() at TestFrame.awaitCompletion.
Impact
This blocks running TestFrameTest/DisplayHandlerTest (or any test using TestFrame's default windowed mode) in any headless/CI environment -- they hang forever rather than failing fast. Worked around in #2 by converting those tests to OSR mode instead (OSR's close handshake is purely Java-side and doesn't depend on native window-destroy notification), but the underlying windowed-mode bug remains unfixed.
Environment
- CEF 146.0.10+g8219561+chromium-146.0.7680.179, linux64
- WSL2 (Ubuntu), and separately bare Xvfb+icewm
Activity
Thrameos commentedon Aug 29, 2026
Worked around (not fixed) in #2 --
TestFrameTest/DisplayHandlerTestconverted to OSR mode to avoid this hang in CI. Seeplan/findings.mdfor the full reproduction across two independent environments.Thrameos commentedon Aug 31, 2026
Re-confirmed today (2026-08-30, separate session) with a fresh dedicated test
(
CefBrowserWrTest,@Disabled, commit fa3afe1): identical symptom --WINDOW_CLOSING->doClose(true)->doClose(false)all fire correctly,then
onBeforeClosenever arrives. Confirmed it's a true hang, not justslow: still stuck after 240s wall-clock (vs. this test's own 30s per-test
watchdog already having force-failed it). Also re-ruled-out "no window
manager" as the cause a second, independent way: same result under a fresh
Xvfb :99+icewm, matching.azure/scripts/coverage.yml's CI setupexactly.
Flagging one thing this issue's original writeup doesn't mention: since
TestSetupExtension.close()is a one-time, suite-global teardown hook, thisisn't just "this one test hangs" -- if a windowed-mode test is ever enabled
without first fixing this, it blocks the entire suite's shutdown on every
run, not just its own test.
Thrameos commentedon Sep 4, 2026
Fixed.
native/util_linux.cpp'sDestroyCefBrowser()now schedules a bounded (2s) fallback viaCefPostDelayedTask-- if CEF's own realOnBeforeClose()hasn't arrived by then, JCEF calls the exact same publicCefLifeSpanHandler::OnBeforeClose()entry point CEF itself would have called. Root cause: CEF's own X11 self-addressedWM_DELETE_WINDOWClientMessage(sent viaCefWindowX11::Close()) is confirmed sent (via gdb) but never processed, so the real close path never completes on its own for a windowed browser under this environment's X11/AWT window hierarchy.CefBrowserWrTest(the first windowed-browser test in the suite) is re-enabled and passing -- verified in isolation. Details:plan/tasks/20260903-03-issue3-windowed-close-onbeforeclose.md.🤖 Generated with Claude Code
Re-enable CefBrowserWrTest (GH #3 fixed); fix run_tests.sh --select-c…
Re-enable CefLifeSpanPopupTest against a windowed browser