Repository navigation
Windowed (non-OSR) browser close never fires onBeforeClose -- hangs indefinitely #3
Description
Activity
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,
thenonBeforeClosenever arrives. Confirmed it's a true hang, not just
slow: 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 setup
exactly.Flagging one thing this issue's original writeup doesn't mention: since
TestSetupExtension.close()is a one-time, suite-global teardown hook, this
isn'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.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
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.onBeforeCloseis never invoked, so any test/app blocking on it (e.g. via aCountDownLatch) 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-> syntheticWINDOW_CLOSINGre-dispatch mechanism.Reproduction
Confirmed reproducible and independent of environment -- identical symptom under two unrelated X setups:
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/cleanupTestnever print.jstackon the hung process shows the main thread parked inCountDownLatch.await()atTestFrame.awaitCompletion.Impact
This blocks running
TestFrameTest/DisplayHandlerTest(or any test usingTestFrame'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