Infrastructure Upgrade - #35

First real GitHub Actions run (PR #35) failed the coverage job in 12s:
apt-get install libtinfo5 errored with "Unable to locate package" --
ubuntu-latest now points at 24.04 ("noble"), which dropped libtinfo5
from the archive. It was only there to satisfy clang-18's prebuilt
binary, which links against the old libtinfo.so.5 SONAME. Symlink the
still-present libtinfo.so.6 to that name instead -- the standard
workaround, since the tinfo ABI surface clang actually touches has
been stable across the bump.

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

Second real GitHub Actions run (PR #35, after the libtinfo5 fix) still
failed all 4 ci.yml jobs plus CodeQL's cpp analysis, all with the same
"ModuleNotFoundError: No module named 'six.moves'" from the vendored
gsutil under tools/buildtools, despite each job already running
`pip install six` (or having a Linux image that supposedly already had
it, per the earlier Azure-only assumption -- false on GitHub's
ubuntu-latest).

Root cause: these runner images carry more than one Python
installation, and CMake's own find_package(PythonInterp) doesn't
reliably resolve to the same interpreter a bare `python`/`python3` on
PATH does -- confirmed in the logs (e.g. macOS: pip installed six into
one python3, CMake picked
/Library/Frameworks/Python.framework/Versions/Current/bin/python
instead; Windows: similar mismatch). A `pip install` that lands in the
wrong interpreter is invisible to CMake's subprocess call.

Fix: after installing six, explicitly pin PYTHON_EXECUTABLE (which
CMakeLists.txt already reads from the environment, see its lines
237-238) to `sys.executable` of the exact interpreter six was just
installed into, via $GITHUB_ENV. Applied to all 4 ci.yml jobs (test
needed six added at all -- GitHub's ubuntu-latest doesn't ship it,
unlike Azure's) and codeql.yml's cpp analysis job.

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

…btinfo5

Third real GitHub Actions run (PR #35) still failed all 4 ci.yml jobs
plus CodeQL's cpp analysis at the exact same CMakeLists.txt:351 six.moves
error -- even after confirming (via macOS's log) that PYTHON_EXECUTABLE
pinning genuinely worked this time (CMake used the exact interpreter six
was installed into). The vendored gsutil script re-execs itself via its
own file, independent of the interpreter that invoked
download_from_google_storage.py, so no amount of environment-pinning
from the CI side can reliably fix this across three different OS images
-- it's fragile old depot_tools-vintage tooling, not something worth
chasing further.

The download is only for clang-format (used by tools/fix_style.sh,
optional dev tooling), not required for the actual jcef/jcef_helper
build -- so stop treating its failure as FATAL_ERROR and downgrade to a
WARNING. This fixes all 4 CI jobs and CodeQL's cpp job in one place,
permanently, rather than re-fighting Python interpreter resolution on
every runner image change going forward.

Separately, the coverage job's libtinfo.so.5 symlink workaround (from
the previous commit) turned out insufficient: clang-18's prebuilt
binary needs the actual NCURSES_TINFO_5.0.19991023 versioned symbol,
not just a file answering to the right name -- confirmed live
("version `NCURSES_TINFO_5.0.19991023' not found"). Fetch the real
libtinfo5 .deb from Ubuntu's archive (still hosted for jammy/22.04 even
though noble/24.04 dropped the package) instead of faking it.

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

CefRequestContext_N.getGlobalContextNative() destroyed the native
wrapper returned by N_GetGlobalContext() only when it happened to be
pointer-identical to the already-cached globalInstance, with no final
else -- so any call after the first, where CEF's
CefRequestContext::GetGlobalContext() returns a different native
wrapper pointer for the same conceptual global context (which CEF does
not guarantee against), leaked that wrapper's CefRequestContext
instance forever. Each leaked instance stayed registered in CEF's
ImplManager, so its DCHECK(all_.empty()) fired on shutdown once enough
had accumulated.

Cherry-picked from b7baff5 on coverage/phase1-value-objects-phase2-handlers
(never merged to master/future or forward-ported here) -- rediscovered
independently via gdb while root-causing PR #35's coverage-job blocker
before finding the existing fix already on record.

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

onGotFocus() unconditionally called browser.setFocus(true), which
synchronously re-fires OnWebContentsFocused -> onGotFocus() again (CEF
guards its own OnSetFocus() against reentrancy but has no equivalent
guard for OnGotFocus/OnWebContentsFocused). Confirmed via live jstack (on
future): a clean two-frame cycle (N_SetFocus <-> onGotFocus) recursing
until the thread's stack overflows -- the source of the "Exception in
thread AWT-EventQueue-0" StackOverflowError storm.

Guard with the already-existing focusedBrowser_ tracking: only call
setFocus() on an actual focus transition, not on every notification.

Cherry-picked from c1e570a on coverage/phase1-value-objects-phase2-handlers
(clean, no conflicts). Found live in this branch's own PR #35 coverage-job
log (repeated, doubling "Exception in thread AWT-EventQueue-0" bursts
immediately preceding the browser_context.cc:44 DCHECK) -- this recursion
storm was present and unaddressed on backport/phase1-ci-infra despite being
root-caused and fixed on future back on 2026-08-31. Per future's own
verification this doesn't fix the separate browser_context.cc:44 DCHECK
(that hypothesis was tested and disproven there), but it is a real,
independent stack-corruption risk worth fixing regardless.

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

…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