Coverage expansion + native coverage fork-safety fix (78 commits) - #30

Two more browser-lifecycle tests for previously-0%-covered native handlers:
- CefJSDialogHandlerTest: native/jsdialog_handler.cpp, via a real alert()
  call from JavaScript. Verified passing in isolation.
- CefRequestContextHandlerTest: native/request_context_handler.cpp, via a
  custom CefRequestContext + CefRequestContextHandler serving a page
  outside TestFrame's own resource-map short-circuit. NOT YET VERIFIED --
  the sandbox's WSLg GPU/display subsystem degraded partway through this
  session (dxg ioctl failures in dmesg; browser_info_manager.cc timeouts
  after fewer and fewer real browser creations per process as the session
  went on, now failing even for a single isolated browser creation). See
  plan/findings.md for the full diagnosis; this is environmental, not a
  code issue, but needs re-verification against a fresh WSL session before
  it can be trusted as passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

TestFrame's constructor unconditionally registers itself as the
CefClient's CefRequestHandler, and getResourceRequestHandler always
returned non-null -- which permanently shadowed any
CefRequestContextHandler passed via a custom CefRequestContext, since
CEF only consults the context handler when the browser-level handler
returns null. CefRequestContextHandlerTest's browser therefore fell
through to a real network request against the literal domain
test.com, hanging until a real (visible, WSLg-passed-through) browser
window needed to be manually closed.

Add TestFrame.delegateToRequestContextHandler_ so a subclass can opt
out of that shadowing, and use it in CefRequestContextHandlerTest so
the request context handler actually gets exercised.

Also harden TestFrame.awaitCompletion() with a bounded wait (default
30s) backed by a try-with-resources watchdog Timer that force-closes
the window/browser on timeout, so any future instance of this bug (or
any other hang) fails the test cleanly instead of leaving a stuck GUI
window that blocks the whole suite until someone closes it by hand.

Filed #10 for an unrelated
Release-build SIGSEGV during JVM shutdown, found while verifying this
fix (happens after all tests already report success; doesn't affect
test correctness).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

WindowlessFrameRateTest -- native/int_callback.cpp via
CefBrowser.getWindowlessFrameRate()/setWindowlessFrameRate().

CefPrintHandlerTest -- native/pdf_print_callback.cpp via
CefBrowser.printToPDF(). Instrumented and confirmed this CEF version's
printToPDF pipeline never actually calls CefPrintHandler.
getPdfPaperSize() for an OSR browser (despite the header describing it
as used in combination with PrintToPDF()) -- the test documents this
and asserts on what does fire: the completion callback and a real
non-empty PDF file.

DragDataFileContentsTest -- native/write_handler.cpp. Initial attempt
paired CefDragData.addFile() (files dragged into the browser) with
getFileContents() (a file being dragged out of the web view, populated
internally by CEF's renderer from a real in-page drag gesture) -- these
are unrelated APIs, so addFile() has no effect on getFileContents().
Test now covers what's reachable without a public API for outbound
drag content: passing a real non-null OutputStream still constructs a
WriteHandler (unlike a null stream, which short-circuits first).

Full suite: 115/115 passing. Logged the two CEF-behavior findings above
plus window_handler.cpp (Windows-only, never invoked from Linux) and
run_file_dialog_callback.cpp (needs a real native file dialog) in
plan/windows-todo.md for follow-up on a Windows checkout.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

CefRequestContextPreferencesTest -- exercises CefRequestContext's
preference accessors from the browser process UI thread (via
onAfterCreated(), as the class's own Javadoc directs), unlike the
existing off-thread no-op coverage in CefRequestContextTest. This is
what actually marshals values through native/jni_util.cpp's
GetCefValueFromJNI*/NewJNIObjectFromCefValue, previously untested.

LoadErrorTest -- first onLoadError coverage in the suite (native/
load_handler.cpp); every other test only follows the happy load path.
Navigates to an unregistered URL under the same intercepted-scheme
pattern every other test uses (no addResource() entry), so the
failure is deterministic and doesn't touch the real network.

Full suite: 118/118 passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

visitorReturningFalseStopsEarly -- CefCookieVisitor.visit()'s own
Javadoc says returning false stops visiting further cookies; not
previously exercised (existing tests always return true).

visitorSettingDeleteRefRemovesCookie -- verifies the visitor's
BoolRef delete parameter actually removes the cookie, distinct from
the explicit deleteCookies() API already covered.

Full suite: 120/120 passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…rect

Previously never triggered -- every other test's resource handler
serves content directly. A CefResourceHandler can redirect a request
by setting getResponseHeaders()'s redirectUrl StringRef instead of
serving content; this test exercises that path and verifies
onResourceRedirect fires with the correct from/to URLs.

Full suite: 121/121 passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

Discovers a genuinely settable preference via canSetPreference() rather
than guessing a Chromium pref name, then pushes a new value through
setPreference() and confirms it round-trips via getPreference(). This
exercises the "Java value going in" direction of
GetCefValueFromJNIBoolean/Integer/Double/String in native/jni_util.cpp,
previously only exercised in the "native value coming out" direction.
Confirmed (via a debugPrint=true run) it found and round-tripped
https_first_mode_incognito_enabled (a Boolean) in this CEF version.

Also lays groundwork for Track A item 3 (CefCommandLine): added an
onBeforeCommandLineProcessing() capture to TestSetupExtension's
CefAppHandlerAdapter, stashed via a new TestSetupContext accessor, since
CefCommandLine has no public factory and this callback is the only way
to obtain a real instance.

122/122 tests passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

CefCommandLine has no public factory (CefCommandLine_N's constructor is
package-private) -- CefAppHandler.onBeforeCommandLineProcessing() is the
only way to obtain a real instance, and it fires once, synchronously,
before any @test runs. Adds that override to the existing
CefAppHandlerAdapter in TestSetupExtension, stashing the browser-process
instance via a new TestSetupContext.getCapturedCommandLine()/
setCapturedCommandLine() accessor pair so a future CefCommandLineTest can
read it -- same harness-capture shape TestSetupContext already uses for
debugPrint.

No behavior change yet (no test reads the captured value); this was
meant to land alongside the previous commit but was left unstaged.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…tems 2/3)

CefCommandLineTest.java exercises CefCommandLine (native/jni_util.cpp string-
vector/map marshaling for it, previously untested -- no public Java factory
exists). Reads back a TestSetupContext.CommandLineSnapshot captured by
TestSetupExtension during onBeforeCommandLineProcessing().

Fixes a real bug discovered while writing that test: TestSetupExtension
registered its own CefAppHandler (constructed with args=null) before calling
CefApp.getInstance(args, settings), which silently discarded the
--disable-gpu/--no-sandbox/etc. flags the harness comment called "required"
-- CefApp's own default onBeforeCommandLineProcessing (which would have
forwarded them) never ran because appHandler_ was already set. Fixed by
passing args through to the custom adapter and delegating to
super.onBeforeCommandLineProcessing().

Also discovered (and worked around) that the live CefCommandLine object is
not safe to hold onto past that callback -- confirmed empirically that
Chromium resets its underlying native state afterward (same Java object
identity, but hasSwitches() flips from true during the callback to false
later). TestSetupContext now stores an eager CommandLineSnapshot (plain
Map/Vector/booleans captured during the callback) instead of the live object.

CefRequestTest/CefPostDataTest: added empty-header-map, empty-header-value,
and zero-length-byte-array edge cases for jni_util.cpp's string/array/map
marshaling (Track A item 2). The empty-file-path CefPostDataElement case
turned out to be a real CEF behavior finding, not a JCEF bug:
SetToFile("") leaves the element type PDE_TYPE_EMPTY rather than
PDE_TYPE_FILE -- the test reflects that rather than the originally assumed
behavior.

130/130 tests passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…omplete)

CefSchemeRegistrarTest.java exercises CefSchemeRegistrar.addCustomScheme()
(no public Java factory -- only obtainable via
CefAppHandler.onRegisterCustomSchemes(), which fires once, synchronously,
during CefApp startup). Same harness-capture shape TestSetupExtension already
uses for CefCommandLine: registers the same scheme name twice back to back
in that callback and stashes both boolean results via a new
TestSetupContext.SchemeRegistrationResults, so the test can assert both the
happy path (first registration of a new scheme succeeds) and the unhappy
path (duplicate registration fails), per addCustomScheme()'s own documented
contract.

This closes out Track A (plan/roadmap.md) -- items 1-3 and 6 landed, items 4
(CefContextMenuParams/CefMenuModel) and 5 (CefDownloadItem) were attempted
and reverted with findings documented for a future retry.

133/133 tests passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

… build dir)

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…l-0%-file targets)

Shotgun round targeting the real still-0%-covered native files identified by
Track B's gcovr run (plan/roadmap.md). CefCookieAccessFilterTest exercises
native/cookie_access_filter.cpp via TestFrame's existing
getCookieAccessFilter() override point. CefKeyboardHandlerTest exercises
native/keyboard_handler.cpp via a synthetic KeyEvent dispatched to the OSR
canvas (works, unlike the earlier context-menu synthetic-dispatch attempt --
key events route differently).

Two other attempts from this same round were reverted after being found to
genuinely hang (not just slow) beyond what TestFrame's watchdog could
recover from -- isolated and confirmed via a hard 45s `timeout` wrapper:

- CefDevToolsClientTest (CefBrowser.getDevToolsClient()/executeDevToolsMethod):
  deleted entirely, no working repro found.
- CefPrintHandlerTest's new browserPrintInvokesPrintStartSettingsAndDialog
  method (browser.print()): reverted, kept only the existing printToPDF test;
  comment updated to reflect the real hang (not just a hypothetical risk).

A third attempt (CefDialogHandlerTest, CefDialogHandler.onFileDialog via a
JS-synthesized file-input click) failed cleanly via the 15s watchdog rather
than hanging, but never actually passed -- consistent with the same
script-doesn't-count-as-a-user-gesture pattern as onBeforePopup/issue #11 and
the CefDownloadItem finding. Deleted rather than left failing, per this
session's established discipline.

135/135 tests passing, ~20s full-suite runtime (back to normal velocity after
isolating and removing the hangs).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…r_N.cpp)

CefBrowser_N.cpp was the single largest remaining gap per Track B's real
gcovr run: 952 lines, only 13% covered. CefBrowserApiTest.java sweeps a wide,
low-risk set of its methods in one shot -- frame enumeration (getMainFrame,
getFrameCount, getFrameIdentifiers, getFrameNames, getFrameByIdentifier),
zoom, find/stopFinding, viewSource, replaceMisspelling, stopLoad,
executeJavaScript, loadRequest, and createScreenshot. All are plain
synchronous or CompletableFuture-based API calls against a live browser --
no synthetic OS-level input events, no user-gesture requirements, so none of
the hang/gesture risk documented elsewhere in plan/roadmap.md for the
context-menu/download/dialog/print/devtools attempts.

Two real findings while getting this to pass cleanly (isolated under a hard
timeout wrapper, not just relying on TestFrame's watchdog):
- getMainFrame()/getFrameByIdentifier() returned null when called from the
  JUnit thread immediately after awaitCompletion() returns, even though the
  page had already finished loading -- moved all such calls into
  onLoadingStateChange() (the CEF UI thread) instead, where they work.
- createScreenshot()'s CompletableFuture needed more than 15s to complete in
  this headless OSR/GL environment; given more headroom (45s) it completes
  reliably.

138/138 tests passing, ~21s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…ered)

Small interface, large gap: CefFrame_N.cpp was only 6% covered per Track B's
real gcovr run. CefFrameApiTest.java exercises all of CefFrame's getters
(getIdentifier, getURL, getName, isMain, isValid, getParent) and edit/script
commands (executeJavaScript, undo, redo, cut, copy, paste, selectAll) against
a live main frame, called from the CEF UI thread (same lesson as
CefBrowserApiTest -- calling from the JUnit thread after the fact returned
nulls for some of these).

139/139 tests passing, ~21s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…13): persistent query success() ignored after first call

Confirmed locally that native/CefQueryCallback_N.cpp's N_Success
unconditionally calls ClearSelf() regardless of the persistent flag, so
CefQueryCallback.success() silently no-ops on any call after the first --
even for a query sent with persistent:true, which is documented to allow
repeated success() calls (the "subscription" style CEF message router
workflow). Matches upstream chromiumembedded#398, still open there
since a report against CEF 87.1.12 -- still reproduces on this fork's current
146.0.10.

UpstreamIssue398Test.java is @disabled with a link to #13
(filed this session) so it doesn't fail the normal suite; confirmed it
genuinely fails (via TestFrame's watchdog cleanly timing out after 10s, not a
real hang) when temporarily un-@disabled. Ready to re-enable once the bug is
fixed.

Also a process note: an earlier draft of this test called assertTrue()
directly inside the CefMessageRouterHandler.onQuery() native callback, which
caused a real unrecoverable hang (not caught by the watchdog) -- moved the
assertion outside the callback (capture a boolean, assert after
awaitCompletion()) instead, matching the existing caution already documented
elsewhere in this suite (DisplayHandlerTest) about uncaught exceptions from
native callback threads.

140 tests found, 1 skipped (this one), 139/139 passing, ~21s full-suite
runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…miumembedded#392 (both confirmed fixed)

Continuing the upstream-issue-harvesting effort (see UpstreamIssue398Test
commit for chromiumembedded#398, and plan/roadmap.md). Both of these upstream reports were
tested against this fork's current CEF version (146.0.10) and found to
already work correctly -- kept as passing regression guards rather than
disabled, since there's nothing currently broken to track, but they document
having checked and will catch a future regression:

- UpstreamIssue365Test (upstream chromiumembedded#365): navigating to a registered-but-
  unhandled custom scheme (added via CefSchemeRegistrar, no
  CefSchemeHandlerFactory attached) correctly invokes onLoadError(). Upstream
  reporters found this broken across CEF 80.x-109.x.
- UpstreamIssue392Test (upstream chromiumembedded#392): a JS fetch() POST's body is fully
  visible via CefRequest.getPostData() in getResourceHandler(). Upstream
  reported it arriving empty for some real-world XHR/fetch requests.

Two other Tier-1 candidates from the triage were evaluated and NOT added:
- Upstream chromiumembedded#362 (CefSettings.background_color has no effect on opaque
  browsers): confirmed the bug is real (native/CefBrowser_N.cpp
  unconditionally forces white when transparent==false) by reading the
  source, but background_color lives on the global CefSettings, applied once
  at CefApp.getInstance() startup -- this fork's whole suite shares one
  CefApp singleton via TestSetupExtension, so there's no way to vary it
  per-test without a separate JVM process per test. Not worth the harness
  change for one bug; documented in plan/roadmap.md instead.
- Upstream chromiumembedded#384 (Accept-Language header override ignored): wrote a test,
  confirmed it passes, then deleted it -- it only proves JCEF's own JNI
  header-marshaling is correct, not the actual upstream claim, which is about
  Chromium's network-service header canonicalization overriding the value
  later, a code path this fork's local-resource-interception test harness
  never reaches. Keeping a misleadingly-named "regression test" that doesn't
  test the real scenario isn't honest; documented the limitation in
  plan/roadmap.md instead.

142 tests found, 1 skipped (UpstreamIssue398Test), 141/141 passing, ~24s
full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…wheel direction inverted

Confirmed locally: native/CefBrowser_N.cpp's N_SendMouseWheelEvent passes
AWT's raw getWheelRotation()/getUnitsToScroll() value straight through as
CEF's deltaY with no sign adjustment, but AWT's "wheel rotated away from the
user" (scroll down) convention is the opposite sign of what CefMouseEvent's
deltaY expects for the same gesture. Matches upstream
chromiumembedded#26, open since 2014, reproductions posted as
recent as CEF 90+.

UpstreamIssue26Test.java dispatches a synthetic MouseWheelEvent (positive
rotation, AWT's "scroll down") to the OSR canvas on a tall page pre-scrolled
to y=500, and confirms window.scrollY afterward. Confirmed via an isolated
run: scrollY went from 500.0026550292969 to 450.1028747558594 -- decreased,
i.e. scrolled up, for a "scroll down" gesture. @disabled with a link to
#14 (filed this session) so it doesn't fail the normal
suite; ready to re-enable once fixed.

Two real process lessons from getting this repro right:
- window.scrollY on an OSR browser is a non-integer float (device-pixel-
  ratio rounding) -- an early draft used Integer.parseInt() on it, which
  threw an uncaught NumberFormatException from inside the onTitleChange()
  native callback thread and caused a genuine unrecoverable hang (same class
  of bug as the assertTrue-in-onQuery() lesson from UpstreamIssue398Test).
  Switched to Double.parseDouble().
- A naive version dispatched the wheel event immediately after a
  programmatic window.scrollTo(), and a {once: true} 'scroll' listener
  registered at the same time raced against that scrollTo()'s own
  asynchronous trailing 'scroll' event -- the listener consumed that leftover
  event instead of one caused by the wheel dispatch, making it look like the
  wheel event did nothing. Fixed by waiting two requestAnimationFrame ticks
  after scrollTo() before signaling readiness and attaching the listener.

143 tests found, 2 skipped (this one, UpstreamIssue398Test), 141/141
passing, ~25s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…15): custom scheme navigation never completes

Root-caused and definitively confirmed: native/util_posix.cpp's
GetTempFileName() concatenates the temp directory path and filename with no
separator, so when CefGetPath(PK_DIR_TEMP) returns a path without a trailing
slash (exactly what Chromium's base::GetTempDir() does on Linux), the
resulting malformed path (e.g. "/tmpjcef-p1234.tmp") means renderer
subprocesses can never find the custom-scheme registration file. The
upstream report was filed from WSL2 Ubuntu -- the same environment this
fork's whole test suite runs in -- with $TMPDIR unset.

UpstreamIssue445Test.java registers a real CefSchemeHandlerFactory for a
genuinely custom (non-http) scheme and navigates to it. Confirmed causation,
not just correlation, via an isolated A/B run: without $TMPDIR set, the page
never loads (watchdog cleanly times out after 15s); with TMPDIR=/tmp/ set
(the exact workaround the upstream report documents), the identical test
passes in ~2s. @disabled with a link to #15 (filed this
session, includes the A/B verification) so it doesn't fail the normal suite.

144 tests found, 3 skipped (this one, UpstreamIssue398Test,
UpstreamIssue26Test), 141/141 passing, ~25s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…via real Set-Cookie response

Tests the same shape as upstream's report (a cookie set via a real
Set-Cookie response header during an actual page navigation, then queried
via CefCookieManager shortly afterward) rather than CefCookieManagerTest's
existing coverage of manually-set cookies via setCookie(). Passes cleanly
for this basic same-origin case. Not a full confirmation the upstream bug is
fixed -- the original report used a real external HTTPS site via a
third-party wrapper library with a same-origin form POST, and there may be a
genuine difference for a cross-origin/third-party-cookie scenario this
fork's local same-origin test doesn't exercise. Kept as a regression guard
for the case it does cover; no fork issue filed (nothing broken to track in
this repro shape).

145 tests found, 3 skipped, 142/142 passing, ~25s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

Targets CefResourceReadCallback_N.cpp/CefResourceSkipCallback_N.cpp, both
0% covered per Track B's real gcovr run. Every other test in this suite
serves resources via the deprecated processRequest()/readResponse() pair
(TestResourceHandler extends CefResourceHandlerAdapter, whose default
open() always signals handleRequest=false to route back to the legacy
path) -- CefResourceHandlerModernApiTest implements the modern
open()/read()/skip() API directly instead. Exercises read() via a plain
fetch() and skip() via a real HTTP Range request (fetch() with an explicit
Range header), confirming both the full-content and range-sliced results
come back correct.

146 tests found, 3 skipped, 143/143 passing, ~26s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

The synchronous modern-API test added earlier this session (open/read/skip
all responding immediately) never actually exercises
CefResourceReadCallback_N.cpp/CefResourceSkipCallback_N.cpp themselves --
those files implement the callback OBJECT's own Continue()/getBuffer() JNI
methods, only reachable via the asynchronous variant of read()/skip()
(bytesRead=0, return true, call callback.Continue() later). Added
AsyncResourceHandler, which defers via a background thread and calls
callback.getBuffer()/Continue() ~50ms later, to close that gap.

147 tests found, 3 skipped, 144/144 passing, ~26s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…efPostDataElement.create() as first native object

Tier A item 1 of the +10%-coverage plan (splitting CefPostDataTest's one
Debug-crashing method into its own class so the rest could rejoin the
coverage measurement) was attempted and reverted -- the split itself changed
JUnit5's default test-class execution order enough to promote the new class
to run first in the whole suite, which crashed the RELEASE build outright:

FATAL:cef/libcef_dll/cpptoc/post_data_element_cpptoc.cc:171]
CefPostDataElement_0_CppToC called with invalid version -1

Confirmed deterministic (twice in a row) via an isolated --select-class run.
Same class of bug as issue #9's "Crash 1" (CefPrintSettings.create() as
first native object), but that was documented as Debug-only -- this shows
it's not build-type-specific, just first-native-object-specific.

Per explicit user instruction this session ("if you find a problem just
disable it and issue file so we have a full list of crash reproducers ready
to go"): kept the minimal repro as @disabled rather than deleting it, filed
as #16. The Tier A split itself was reverted (see
CefPostDataTest.java, back to its prior committed state) since it's not
safe to keep -- also flags a broader fragility worth tracking regardless of
coverage-measurement goals: the whole suite's current test order is
silently load-bearing for correctness.

148 tests found, 4 skipped, 144/144 passing, ~26s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…it user instruction

Earlier this session several genuinely-failing test attempts were deleted
outright rather than kept -- losing the reproducer each time. Per explicit
user direction ("In general if you find a problem just disable it and issue
file so we have a full list of crash reproducers ready to go"), restored
all of them as @disabled tests (reconstructed from this session's earlier
work, since none were ever committed) and filed fork issues for the two
that didn't already have one:

- CefContextMenuTest.java: onBeforeContextMenu never fires for a synthetic
  OSR right-click. Root cause not yet isolated. Filed as new issue #17.
- CefDownloadItemTest.java: onBeforeDownload never fires despite Chromium
  correctly detecting the download (ERR_ABORTED). Filed as new issue #18.
- CefDialogHandlerTest.java: onFileDialog never fires for a script-
  synthesized file-input click -- same user-gesture-requirement class as
  onBeforePopup/issue #11, no new issue filed (dedup).
- CefDevToolsClientTest.java + CefPrintHandlerTest's
  browserPrintInvokesPrintStartSettingsAndDialog(): both genuinely
  UNRECOVERABLE hangs (confirmed via a hard external `timeout -k` wrapper,
  TestFrame's own watchdog never even got a chance to run) -- both already
  covered by issue #12, restored with strong "do not remove @disabled"
  warnings given the severity.
- CefAuthCallbackTest.java: getAuthCredentials never fires for a locally-
  intercepted 401 response -- same harness-architecture limitation class as
  upstream issue chromiumembedded#384 (real network-service-layer behavior this suite's
  local resource-interception can't reach), not filed as a new issue.

154 tests found, 10 skipped, 144/144 passing, ~26s full-suite runtime.
(One transient flake observed and confirmed non-reproducing on retry:
UpstreamIssue405Test's cookie-visibility timing -- unrelated to this
commit's changes, not investigated further.)

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…rement (Tier A item 2)

Bisected via --select-method isolation (not a risky whole-class split like
the reverted CefPostDataTest attempt, see issue #16): only
frameNavigationAndZoomApis() triggers the Debug/coverage-build mojo crash
(interface_endpoint_client.cc:538, via viewSource()/find()/stopFinding()).
executeJavaScriptAndLoadRequestDoNotThrow() and
createScreenshotReturnsARealImage() don't, individually confirmed clean.

Moved those two into a new CefBrowserApiDebugSafeTest class, left the
crashing method alone in CefBrowserApiTest (now excluded by name from the
coverage run, same as before, just smaller). Unlike the CefPostDataTest
split, this doesn't carry the first-native-object-in-the-process risk since
both methods create a real browser before doing anything else -- confirmed
safe by actually running the full suite in both Release and the coverage
build after the change (not just assumed): Release stays 154/154 (10
skipped), and the coverage build reaches its normal end-of-suite shutdown
crash cleanly with all 72 .gcda files written, no new crash signature.

Real result: CefBrowser_N.cpp (the single largest remaining gap) went from
13% to 22% covered. Updated report saved to plan/coverage-native-current.txt.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

Exercises real back/forward navigation history (canGoBack/goBack/
canGoForward/goForward via two real page loads), reload()/
reloadIgnoreCache(), and setFocus()/setWindowVisibility() -- more of
CefBrowser_N.cpp's still-large gap.

Real lesson: an early draft called browser.canGoBack()/canGoForward()
directly from inside onTitleChange() and got a stale/false answer --
history-entry commit apparently can lag the title-change event slightly.
Switched to sequencing via onLoadingStateChange() instead, which hands
canGoBack/canGoForward directly as parameters and is the more reliable
signal already used elsewhere in this suite for multi-step navigation
flows.

156 tests found, 10 skipped, 146/146 passing, ~27s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

Targets jni_util.cpp's null-guarded JNI marshaling helpers (GetJNIString:
"if (!jstr) return CefString();", GetJNIStringMap/GetJNIStringMultiMap:
"if (!jmap)"/"if (!jheaderMap)") -- previously untested, since every other
test in this suite only ever passes real, non-null values. None of the
Java-side *_N.java setter wrappers null-check their arguments before
calling into native, so a null argument reaches these native guards
directly. Per the 85%-coverage goal's explicit "happy AND unhappy paths"
requirement.

All 4 methods pass cleanly -- no crashes from any of the null inputs tried
(setURL/setMethod/setHeaderByName/setFirstPartyForCookies/setHeaderMap on
both CefRequest and CefResponse). Confirmed the class is safe within the
full suite's actual execution order (not just in isolation, where it
reproduces the same already-known "first native object in the process"
issue every value-object test does when run completely alone, see #9/#16 --
not a new bug, just the same one).

160 tests found, 10 skipped, 150/150 passing, ~26s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

…l crash

Per explicit user direction ("continue with a big bang bad path test
write") and the earlier discussion of null-parameter coverage value:

- NullParameterEdgeCaseTest: added CefRequest.set() with all-null arguments,
  CefPostDataElement.setToFile(null), CefCookieManager.setCookie() with a
  fully-null-fielded CefCookie, CefMessageRouterConfig with null function
  names passed to CefMessageRouter.create(). All pass cleanly.
- MalformedInputEdgeCaseTest (new): numeric/size-mismatch edge cases --
  CefPostDataElement.setToBytes() with an oversized or negative size,
  CefPostDataElement.getBytes() with a zero-size buffer, CefRequest.setFlags()
  with extreme int values, CefRequest.setURL()/setHeaderByName() with empty/
  malformed strings.

Found a real, previously-unknown crash: CefPostDataElement.setToBytes(-1,
data) crashes the JVM with a SILENT segfault (no FATAL/DCHECK output at
all, unlike every other crash found this session -- consistent with a raw
memory-safety bug rather than a deliberate assertion). Root-caused to
native/CefPostDataElement_N.cpp passing the jint |size| straight into
CefPostDataElement::SetToBytes(), whose C++ signature takes a size_t -- a
classic signed/unsigned integer bug (negative jint becomes a huge unsigned
value). Filed as #19. Kept the reproducer as @disabled
per this session's "never delete a repro" policy, not deleted.

170 tests found, 11 skipped, 159/159 passing, ~26s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

… args

CefResponse.setStatus() with negative/zero/huge/extreme int values,
CefCookieManager.deleteCookies() with null url/cookieName in every
combination. All pass cleanly.

172 tests found, 11 skipped, 161/161 passing, ~26s full-suite runtime.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

Re-running Track B's Debug/coverage measurement with this session's new
tests included surfaced a real crash: CefRequest.setHeaderByName("", value,
true) (empty header NAME) hits a CHECK(!name.empty()) inside CEF's own
bundled binary distribution (request_ctocpp.cc) -- confirmed Debug-only,
does not reproduce in Release. native/CefRequest_N.cpp does no validation
before forwarding straight through. This crash also happened early enough
to prevent CoverageTestHelper.flush() from running, losing an entire
coverage-measurement run's .gcda data (0 files written).

Split requestSetHeaderByNameWithEmptyStringsDoesNotThrow() into two:
requestSetHeaderByNameWithEmptyValueDoesNotThrow() (kept, confirmed safe --
an empty VALUE is fine) and requestSetHeaderByNameWithEmptyNameDoesNotThrow()
(the crashing one, @disabled, linked to #20).

173 tests found, 12 skipped, 161/161 passing, ~26s full-suite runtime
(Release; the coverage/Debug build measurement itself needs a re-run with
this fix, not done again this session -- see plan/roadmap.md).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01BLqFiEqAPbHc3MifgpNjA8

TestSetupExtension.initialize()'s warmUpBrowserProcess() (create and
close one throwaway real browser before any test body runs) was only
invoked for the isolated leak-sweep case. Any *_N value-object's
create() (CefPostDataElement, CefRequest, CefPrintSettings, ...) hit a
native FATAL ("CppToC called with invalid version -1") when it was the
first real CEF call in the process instead -- reproduces in Release,
not just Debug/coverage, and is order-dependent on which test class
JUnit5 happens to discover first (a real, silent fragility in the
existing full suite, independent of the coverage-measurement work that
originally surfaced it).

Root cause: this repo's real default (windowless_rendering_enabled=true,
external_message_pump mode) drives CEF's browser-process/IO-thread
startup only via explicit doMessageLoopWork() calls -- some CEF-internal
state only finishes initializing as a side effect of creating a browser,
which every real embedding app does before touching one of these value
types anyway. Made warmUpBrowserProcess() unconditional so every test
run (including a single class selected in isolation) starts from that
same precondition.

Verified: CefPostDataElementFirstNativeObjectTest (this fix's own
regression test) now passes 3/3 in complete isolation; full suite still
passes clean, 187/187 (up from 184-186/185-186 pre-fix, since this
re-enables 2 more tests and doesn't reproduce the earlier session's
intermittent flakes this run).

Also re-enables CefPostDataTest.elementSetToEmptyFilePathLeavesElementEmpty
(#28, already fixed/closed) now that it no longer collides with #16 in
test discovery order.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01AQiFSc2Erh2KaLAaHarU4f

Mirrors native/context.cpp's exact init/pump/shutdown sequence
(windowless_rendering_enabled=true, external_message_pump=true, manual
CefDoMessageLoopWork() pump loop -- unlike tools_native/leak_probe.cc,
which deliberately uses the opposite multi_threaded_message_loop=true
mode and has never reproduced this crash) plus, after direct comparison
against native/CefBrowser_N.cpp, the exact browser-creation call shape:
async CefBrowserHost::CreateBrowser() (not the sync variant) with
CEF_RUNTIME_STYLE_ALLOY explicitly set, matching that file's own
"JCEF requires Alloy runtime style" comment.

Result: does not crash, 3/3 runs, with either version (sync+default-
runtime or async+Alloy-runtime) of the browser-creation call. Confirms
CEF-API-level call order/shape is not the divergence. See plan/roadmap.md
and the issue_4_23_mental_model memory for the full writeup and what
remains untested (this repro is single-threaded; real JCEF runs inside a
JVM process with 20-30+ other threads and glibc's malloc uses per-thread
arenas, a real, unverified variable).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01AQiFSc2Erh2KaLAaHarU4f

…othesis

ISSUE10_REPRO_MODE=thread runs every CEF UI-thread-affine call from one
consistently-used spawned std::thread instead of main() (verified this
doesn't violate CEF's actual single-UI-thread contract -- real JCEF
itself uses AWT-EventQueue-0, never the JVM's main thread, so this
mirrors that exactly). ISSUE10_REPRO_MODE=busythreads additionally spawns
N idle background threads (default 24, never touching any CEF API) doing
periodic small heap churn, testing whether thread-count/glibc-arena
pressure alone matters.

Result: both survive, 3/3 each. Rules out "not the process's initial
thread" and "many concurrent threads doing generic heap churn" as
explanations for issue #10's SIGSEGV. See plan/roadmap.md and the
issue_4_23_mental_model memory for the full ladder and remaining
candidates.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01AQiFSc2Erh2KaLAaHarU4f

Added the same JCEF_TRACE() facility native/context.cpp/life_span_handler.cpp/
client_handler.cpp use, with matching trace strings, so this repro's trace
output can be diffed directly against a real JCEF trace line-for-line.

ISSUE10_REPRO_LATE_CLOSE=1: per the user's direct suggestion -- rather than
chase JVM GC/finalizer timing, directly simulate what a late finalizer
would do (CefBrowser_N.java's finalize() calls close(true) i.e.
GetHost()->CloseBrowser(true)) on a browser that was never explicitly
closed before CefShutdown(), called immediately after instead.

Result, decisive: in a JCEF_ENABLE_TRACE Debug build, this reproduces
issue #4/#23's ORIGINAL `DCHECK failed: all_.empty()` at
browser_context.cc:44 -- in pure C++, zero JVM involved -- 3/3, and the
trace confirms it fires INSIDE CefShutdown() itself (the post-shutdown
CloseBrowser() call never even runs). In Release, the identical scenario
survives -- but the trace shows CefShutdown() itself force-closes the
still-open browser as part of its own internal teardown (OnBeforeClose
fires synchronously during CefShutdown(), before it returns), so the
DCHECK in Debug is asserting a state Release's subsequent code already
handles gracefully, at least for one browser. The real issue #10
mechanism therefore needs to be more specific than "one browser closed
sequentially after shutdown" -- likely a genuine race between a stray
finalizer and CefShutdown()'s own internal force-close, not a simple
before/after ordering. See plan/roadmap.md and the issue_4_23_mental_model
memory for the full writeup and next steps.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01AQiFSc2Erh2KaLAaHarU4f

22 Java classes have finalize() methods that call into native code if
the object was never explicitly disposed by application code (a browser,
frame, request, response, post-data value, drag-data, registration,
message router, or one of ~10 callback types) -- Java finalizers run
asynchronously on the JVM's own Finalizer thread with no ordering
guarantee relative to CefApp.dispose()/CefShutdown(). Confirmed via
tools_native/issue10_repro's ISSUE10_REPRO_LATE_CLOSE mode that touching
CEF after it has already been shut down is a real, reproducible trigger
for corruption (reproduced the original browser_context.cc:44 DCHECK in
pure C++, zero JVM).

Two-part fix:
- jni_scoped_helpers.h's SetCefForJNIObjectHelper::Release(CefBaseRefCounted*)
  is the single choke point ~20 of these classes' dispose() paths already
  funnel through (via SetCefForJNIObject_sync) -- guarded there once,
  covers all of them centrally.
- The remaining classes' finalize() calls a semantic method directly
  (CefBrowser_N's close(true), and ~8 callback classes' cancel()/
  Continue()/Failure()) rather than a plain dispose() -- added a new
  JNI_REQUIRE_CEF_ALIVE_OR_RETURN macro (jni_util.h, matching the same
  Context::GetInstance()-null check CefApp.cpp's N_DoMessageLoopWork
  already uses) at each of those individual native entry points.

Verified: full Release suite still passes clean, 187/187, no regression.
Verified directly: a scratch test (not committed) that creates a
CefRequest, deliberately never disposes it, and calls dispose() on it
immediately after a real CefApp shutdown (simulating a late finalizer
deterministically instead of relying on GC timing) now survives cleanly
where it would previously be expected to corrupt state -- confirmed the
guard's "SURVIVED" path is actually reached.

Does NOT single-handedly resolve issue #10 -- a baseline isolated-single-
test-class run (e.g. CefCommandLineTest, which creates no finalizable
object of its own at all) still crashes with the identical
libc.so.6+0x91651 signature independent of this fix, confirming a second,
still-unexplained mechanism produces the same signature. This fix closes
one confirmed, real trigger; #10 stays open. See plan/roadmap.md and the
issue_4_23_mental_model memory for the full writeup.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01AQiFSc2Erh2KaLAaHarU4f

Root-caused via gdb (jpype technique: launch under `handle SIGSEGV nostop
noprint pass`): N_Close(force=true) triggers CEF's FastShutdown() path,
which tears down the renderer's mojo RenderFrame connection without
waiting for in-flight calls. find()/viewSource() fired just before close
leave a pending mojo responder, and InterfaceEndpointClient::PassHandle()
DCHECKs on it (compiled out in Release, live in Debug/coverage builds).

JCEF has no CefFindHandler binding (filed as #32), so there's no way to
actually wait for find()'s async completion before closing, unlike CEF's
own find_handler_unittest.cc. Mitigate by giving the CEF UI thread's
message pump a short settle period before closing -- verified 5/5 clean
isolated runs plus the class's original 6-class batch run.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MkDJ47HR6QSHPCkKdHCodp

native/jni_util.cpp's GetCefValueFromJNIMap built a populated
CefDictionaryValue from the Java Map but returned a brand-new, empty
CefValue instead of attaching it via SetDictionary() -- its List sibling
does this correctly via SetList(). Every Java Map ever passed to
CefRequestContext.setPreference() silently lost all its data as a result.
Found while tracing jni_util.cpp's real coverage gaps (via the LLVM
coverage build) for GetCefValueFromJNIInteger/Double/Map/List/ByteBuffer,
none of which any existing test reaches.

Added setPreferenceWithEachUnmappedJavaTypeDoesNotThrow(), which exercises
all five conversion functions directly via setPreference() with a
guaranteed-unsettable key -- per CefRequestContext_N.cpp's N_SetPreference,
the Java->CefValue marshaling always runs before CEF's own rejection, so
this reaches the code regardless of build-specific preference availability.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MkDJ47HR6QSHPCkKdHCodp

…nge finding

Switched the synthetic mouse-move to canvas.dispatchEvent() (matching
CefContextMenuTest's proven working pattern for right-click) instead of
calling registered listeners directly. Traced the full path
(CefBrowserOsr's MouseMotionListener -> sendMouseEvent -> N_SendMouseEvent
-> CefBrowserHost::SendMouseMoveEvent) and confirmed it's an unfiltered,
direct pass-through either way -- dispatchEvent didn't fix onCursorChange's
unreliability in isolation (5/5 runs still don't fire), so this stays a
soft, non-fatal signal, not an assertion. Documented the tracing finding in
the class comment.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MkDJ47HR6QSHPCkKdHCodp

find()/stopFinding() were fire-and-forget from Java: no way to observe
when an in-page find settles, or to know it's safe to close/tear down
a browser without a find request's mojo IPC still in flight (the root
cause behind CefBrowserApiTest's earlier settle-delay workaround for
GH #27's Debug/coverage-build DCHECK).

Add native/find_handler.{h,cpp} + org.cef.handler.CefFindHandler,
wired into client_handler.cpp/CefClient the same way every other
handler type is (JSDialogHandler is the closest existing pattern).
CefBrowserApiTest now waits on the real onFindResult(finalUpdate=true)
before calling stopFinding()/closing, replacing the blind delay.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018bVfz6ZK8qYAfqN8i9XHgj

Two more CefClient-level handlers CEF exposes that JCEF had no Java
binding for at all:

- CefFrameHandler: frame lifecycle (onFrameCreated/Destroyed/Attached/
  Detached, onMainFrameChanged). Wired the same way as CefFindHandler.
  Covered by CefFrameHandlerCoverageTest (data: URL iframe exercises
  the sub-frame created/attached path deterministically).

- CefPermissionHandler: onRequestMediaAccessPermission,
  onShowPermissionPrompt, onDismissPermissionPrompt. Previously there
  was no way for a JCEF app to grant/deny camera, mic, or geolocation
  requests at all -- Alloy style silently denies everything. Adds
  CefMediaAccessCallback and CefPermissionPromptCallback (new _N
  callback classes, following the CefJSDialogCallback_N pattern).
  Permission result/media-permission-type bit flags are passed as raw
  ints with a nested constants class (CefContextMenuParams.TypeFlags'
  existing convention), matching cef_media_access_permission_types_t/
  cef_permission_request_result_t's declaration order exactly. Not
  covered by an automated test: getUserMedia() requires a secure
  context and loadPage()'s test URLs are http://test.com, so the
  request would be rejected by Blink before ever reaching CEF's
  permission layer.

Both verified with a full native rebuild under -Werror (confirms the
hand-edited generated JNI headers match javac -h's output).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018bVfz6ZK8qYAfqN8i9XHgj

SetCefForJNIObjectHelper::GetLiveObjectCount() tracks how many CEF-backed
Java wrapper objects JCEF thinks are still alive, logged via JCEF_TRACE in
Context::Shutdown() at both ends of the pre-CefShutdown() pump. Used to
test whether JCEF-visible async work is stranded at shutdown time -- result
was a clean negative (0 on every crashing CefCommandLineTest run), ruling
out that theory for this crash's mechanism. Left in place as a real,
reusable diagnostic signal.

Also adds ISSUE10_REPRO_RACE_CLOSE to tools_native/issue10_repro/: a second
thread calls CloseBrowser(true) timed to race CefShutdown(), the one
"late close" variant not yet tried. Didn't find a new repro path (20/20
Debug hit the already-known DCHECK regardless of timing; 20/20 Release
survived), but is available for further work.

See the issue_4_23_mental_model and issue10_shutdown_phasing_hypothesis
memories, and GH issue #10's comment thread, for the full investigation
this instrumentation supported.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L5YMhmykXCfU4fXTY8ytsW

browser whose renderer already died

Caught live during regression testing: a full-suite run hung indefinitely
(37+ minutes, no watchdog) in TestSetupExtension.close()'s final
CefApp.dispose() pass. Root cause: CefRequestHandlerCoverageTest's
deliberate chrome://crash navigation kills its browser's renderer process;
closing that browser later during suite-wide teardown does not reliably
fire a real LifeSpanHandler::OnBeforeClose(), so CefClient's
cleanupBrowser() never sees browser_ go empty, clientWasDisposed() is never
called, CefApp's clients_ set never empties, and native shutdown() is never
invoked at all -- an unbounded hang, not a crash.

Generalizes the existing windowed-close (X11) fallback -- a bounded,
idempotency-guarded synthesized OnBeforeClose() already used for the
WM_DELETE_WINDOW hang -- to the OSR force-close path too, via a new shared
util::ScheduleOnBeforeCloseFallback() (native/util.h, native/util_linux.cpp,
called from native/CefBrowser_N.cpp's N_Close()). Also gives
TestSetupExtension.close()'s previously-unbounded countdown_.await() a 30s
bound, so any future variant of this fails fast instead of hanging CI.

Verified: the exact repro (CefRequestHandlerCoverageTest alone) now
completes cleanly instead of hanging; a full-suite run completes in ~44s
with only one pre-existing, already-documented flaky UI-timing failure
(CefFocusHandlerCoverageTest.tabPastLastElementInvokesOnTakeFocus), down
from that plus two CefRequestContextPreferencesTest timeouts observed
before this fix (both were downstream symptoms of the same hang blocking
the whole suite's final teardown, not independent failures).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L5YMhmykXCfU4fXTY8ytsW

….cpp

CefPermissionHandler (added in 17ba666) had zero test coverage at all --
found via the fresh coverage baseline this session, native/
permission_handler.cpp's OnRequestMediaAccessPermission had never been
exercised.

Modeled on ~/devel/cef/tests/ceftests/media_access_unittest.cc: getUserMedia()
does not require a user gesture (unlike window.getScreenDetails(), the other
API that reaches this handler, which does -- deliberately avoided here since
synthetic-gesture delivery is documented elsewhere in this suite as
unreliable, see CefContextMenuTest/CefDisplayHandlerCoverageTest), so the
request is triggered directly from a <script> on page load.
--use-fake-device-for-media-stream (TestSetupExtension, matching the ceftest
reference's own flag) supplies a synthetic camera/mic so this works without
real hardware, without bypassing the permission handler -- the request still
reaches onRequestMediaAccessPermission and must be explicitly resolved.

Each test uses its own TestFrame + a fresh in-memory CefRequestContext
(matching the ceftest reference's per-scenario context) rather than
SharedBrowserExtension's long-lived shared one, so accept/deny results from
one scenario can't leak into another via per-origin permission state in a
shared profile.

Covers both the accept path (onRequestMediaAccessPermission returns true,
callback.Continue()) and the default-deny path (returns false, exercising
permission_handler.cpp's jresult==false branch). OnShowPermissionPrompt/
OnDismissPermissionPrompt remain uncovered -- reaching them needs a real
user gesture, out of scope here for the same reliability reason.

Verified via jcef_build_llvmcov: permission_handler.cpp 0.00% -> 35.94%
(0 -> 41 of 64 lines).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L5YMhmykXCfU4fXTY8ytsW

getFrameByName, startDownload, and 5 drag-target/source methods

Found via the fresh jcef_build_llvmcov sweep this session (plan/
coverage-current-state.md's 2026-09-03 entry) -- CefBrowser_N.cpp is the
single biggest coverage gap in the codebase and has been for weeks.

CefBrowserApiGapCoverageTest (new): isLoading()/getFocusedFrame()/
getFrameByName() via SharedBrowserExtension (simple, no risk); startDownload()
via a dedicated TestFrame + CefDownloadHandler, matching CefDownloadItemTest's
existing pattern but triggering the download explicitly from Java rather
than via page content, to reach N_StartDownload directly.

DragTargetTest: generalized its existing dragTargetDragEnter() reflection
helper (CefBrowser_N's DragTarget*/DragSource* methods are protected,
package-internal, only reachable this way -- same technique CEF's own
os_rendering_unittest.cc uses at the C++ level) to also cover
dragTargetDragOver/dragTargetDragLeave/dragTargetDrop/dragSourceEndedAt/
dragSourceSystemDragEnded, none of which fire a Java-visible callback of
their own (pure pass-throughs to CefBrowserHost) -- structural coverage,
asserting they don't throw.

Deliberately NOT touched: browser.print() (native/CefBrowser_N.cpp's
N_Print) and openDevTools()/N_CreateDevTools -- see #12 and
CefPrintHandlerTest's own @disabled test, print() has a documented genuine
unrecoverable hang risk and must not be called from a normal suite run.

Verified: CefBrowser_N.cpp 41.12% -> 45.78% line coverage (733 -> 675 of
1245 missed) via jcef_build_llvmcov. All 8 new/changed tests pass together
repeatably; also confirmed (by fully reverting these files and rebuilding)
that a full-suite Trace/breakpoint trap crash seen while regression-testing
this change reproduces identically without it -- the pre-existing,
long-documented #4/#23/#10 full-suite Heisenbug, not a regression from this
commit.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L5YMhmykXCfU4fXTY8ytsW

Many CefBrowser_N.cpp accessors (getURL, canGoBack, getMainFrame, etc.)
show exactly 50% region coverage: the "browser alive" path is well-tested,
but JNI_GET_BROWSER_OR_RETURN's early-return-after-close branch never is,
across ~20 functions.

accessorsReturnSafeDefaultsAfterBrowserIsClosed() closes a browser then
calls a batch of accessors on the now-dead reference in one pass, rather
than one test per function. Currently @disabled: hangs (30s watchdog) --
terminateTest() appears to race the browser's own async creation rather
than anything about the accessor calls themselves. Not root-caused this
session; kept in the tree (not deleted) as the fastest path back into the
hang for whoever picks this up next, per this project's own reproducer
policy (plan/roadmap.md's "never discard a crash reproducer" entry).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L5YMhmykXCfU4fXTY8ytsW

… data, cookies, dialogs, downloads, message router, post data, request context, URL request)

Extends CefCookieManagerTest, CefDialogHandlerTest, CefDownloadItemTest,
CefFrameApiTest, CefMessageRouterTest, CefPermissionHandlerCoverageTest,
CefRequestContextPreferencesTest, CefURLRequestTest, and DragDataTest, and
adds CefPostDataGapCoverageTest, each targeting a specific previously-0%
native downcall/upcall identified in the 2026-09-03 clang-18 coverage sweep.
Full per-function breakdown in plan/tasks/20260903-02-coverage-gaps-table.md.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015ukhz25kptPVnvbzueEVpq

…efixed

Audited all 79 files in java/tests/junittests/ against the 142 source
classes in java/org/cef/ (task 20260903-18). Nearly everything already fit
one of six naming patterns once made explicit; only DisplayHandlerTest.java
and DragDataTest.java had actually drifted (tested a Cef-prefixed class but
lacked the prefix themselves). Renamed those plus
DragDataFileContentsTest.java (same family/gap) to their Cef-prefixed
names, updated the few in-file comments that referenced the old names, and
documented the full convention plus exception categories in a new
java/tests/junittests/README.md.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

…ler.cpp

CefPermissionHandlerCoverageTest only exercised OnRequestMediaAccessPermission,
leaving OnShowPermissionPrompt/OnDismissPermissionPrompt at 0%. Ports the
Window Management scenario from CEF's own permission_prompt_unittest.cc
(window.getScreenDetails(), which requires a real user gesture unlike
getUserMedia()), using CefTestHelper.executeJavaScriptWithUserGestureForTests
instead of unreliable synthetic mouse input. Remaining 6 missed regions are
the generic unreachable ScopedJNIEnv guard branches, not addressable from
application-level tests.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

…lass

CefBrowserWrTest's windowed-close hang was already fixed in a prior session
(native/util_linux.cpp's bounded OnBeforeClose fallback); its remaining
blocker, the #4/#23 shutdown DCHECK, is now closed. Re-enabling surfaced one
more pre-existing, already-documented gotcha in the test itself (getURL()
returning empty when called from the JUnit thread after awaitCompletion()
instead of from within the callback on the CEF UI thread, same as
CefBrowserApiTest) -- fixed by capturing the URL inside the callback.

Also fixes tools/run_tests.sh: --select-class was silently additive to the
script's own hardcoded --select-package tests.junittests (JUnit ORs
selectors rather than intersecting them), so a "run just this one class"
invocation was actually running the whole suite. Now the default package
selector is only appended when the caller didn't pass their own --select-*.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

OnBeforePopup is unreachable for OSR browsers (native/life_span_handler.cpp
unconditionally cancels+returns when IsWindowRenderingDisabled()), which is
why this test was disabled. Its blocker, GH #3 (windowed close hang), is
fixed and CefBrowserWrTest is passing, so switch this test to a windowed
browser (useOSR=false) the same way and drop the @disabled. Verified passing
in isolation; window.open() correctly reaches onBeforePopup with the right
target URL/frame name and is cancelled.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

CefMessageRouter_N.cpp's local GetHandler() unconditionally constructed a
ScopedJNIObject over jrouterHandler before checking it, even though
cancelPending()'s own Javadoc documents the handler as nullable. That
constructor DCHECKs its handle is non-null, so a null handler crashed the
process. GetJNIBrowser()/GetCefFromJNIObject_sync() already null-checks its
own argument, so only the routerHandler side needed the guard.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

…nBeforeUnloadDialog

Closes a Bucket D gap from task 20260903-16: OnBeforeUnloadDialog was 0%
covered. Uses a dedicated TestFrame-based browser (not the shared-browser
harness) to avoid destabilizing SharedBrowserExtension state, and CEF's
own executeJavaScriptWithUserGestureForTests helper to satisfy Blink's
user-gesture requirement for firing window.onbeforeunload.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

…ge gap; migrate leak-sweep onto it

Introduces a reusable IsolatedTask/IsolatedRunner/IsolatedTaskRunnerTest
harness: dispatches a named task into a disposable, process-isolated
JVM+CefApp subprocess (spawned via tools/run_tests.sh, results marshaled
back over stdout via java.util.Properties between marker lines), adapting
~/devel/jpype/test/jpypetest/subrun.py's pattern to this project's
constraints (no closure serialization across JVMs, native-library wiring
that tools/run_tests.sh already builds correctly).

Uses it to close CefCommandLine_N.cpp's 6 previously-uncovered downcalls
(N_Reset/N_GetProgram/N_SetProgram/N_HasSwitch/N_GetSwitchValue/
N_AppendArgument, CefCommandLineMutationTest + CefCommandLineMutationTask):
mutating the real, live browser-process CefCommandLine was previously
judged too risky for the shared suite process, since no isolation
mechanism existed. Found and fixed a real bug along the way: naively
restoring the command line's program string crashed the Debug/coverage
build with `CHECK failed: !program.empty()` (CEF's SetProgram() rejects
empty strings, and the real value is legitimately empty here).

Migrates LeakSweepTest's hand-rolled -Dleak.isolated=true/Runtime.halt()/
LEAK_SWEEP_RESULT: convention onto the same harness
(LeakSweepIsolatedTest + LeakSweepTargetTask), so only one process-
isolation mechanism needs maintaining. tools/run_leak_sweep_isolated.sh
keeps its original CLI as a thin wrapper. Default pool size raised from 1
to Runtime.availableProcessors() now that per-target isolation is proven
correct -- a full machine-core-count soak is the normal way to run this,
not something to opt into.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

Infrastructure Upgrade

…oval) into coverage/phase1-value-objects-phase2-handlers

Resolves all conflicts arising from the phase1-ci-infra backport
(squashed into master via PR #35) overlapping this branch's own,
independently-developed history of the same fixes. Conflict resolution
approach, file by file:

- CMakeLists.txt / native/CMakeLists.txt / native/CoverageTestHelper.cpp
  / java/tests/junittests/CoverageTestHelper.java / .github/workflows/
  ci.yml / java/tests/junittests/NullParameterEdgeCaseTest.java: took
  master's side -- these are exactly the ENABLE_COVERAGE (gcov) removal
  and JaCoCo-flush fix landed on master, which this branch never had.
  ENABLE_ASAN, JCEF_ENABLE_TRACE, and ENABLE_LEAK_CHECKER (options each
  side added independently) are combined, not chosen between.
- native/jni_scoped_helpers.h, native/jni_util.h, native/util_linux.cpp,
  native/life_span_handler.cpp, native/context.cpp: kept this branch's
  JCEF_TRACE instrumentation throughout (master predates that facility
  entirely), while folding in master's side where it was a real,
  independent fix (none here -- these were all pure superset additions).
- native/CefRequest_N.cpp, native/CefResponse_N.cpp,
  native/CefPostDataElement_N.cpp: kept this branch's stricter empty-
  string guards (checks the decoded CefString for .empty(), catching an
  explicit empty Java string "" as well as null) over master's narrower
  null-only checks.
- native/CefBrowser_N.cpp, native/CefClientHandler.cpp: clang-format
  line-wrapping differences and additive #include lines (find_handler.h/
  frame_handler.h/permission_handler.h, dev-branch-only features master
  doesn't have) -- straightforward union.
- java/tests/junittests/TestSetupExtension.java: kept this branch's
  broader fix (issue #16's warmup precondition applies to every test
  run, not just isolated leak-sweep processes, per this branch's later
  investigation) and its CefCommandLine mutation-probe helper method,
  which master's smaller backport slice never included.
- java/tests/junittests/DisplayHandlerTest.java (modify/delete): kept
  this branch's deletion -- already superseded by the Cef-prefixed,
  shared-browser-harness rewrite (CefDisplayHandlerTest.java), which
  already carries forward the same onTitleChange/onAddressChange
  idempotency-guard fix master's version of the old file also has.
- java/tests/junittests/CefDownloadItemTest.java, .github/workflows/
  codeql.yml: took master's side -- both are strict supersets (the
  world-readable-temp-file fix, and a six/PYTHON_EXECUTABLE CodeQL
  build-environment fix) this branch never picked up.
- tools/run_tests.sh: kept this branch's fix (only defaults to
  --select-package when the caller didn't already pass their own JUnit
  selector, since JUnit ORs multiple selectors together rather than
  intersecting them).

Verified post-merge: a fresh configure + `ninja jcef` (Release, default
options) and `tools/compile.sh linux64` both succeed with no errors (Java
compile warnings are pre-existing, unrelated deprecation notices) and no
stray conflict markers anywhere in the tree (grep -rn on all touched
files).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq