Skip to content

Fix GetCefValueFromJNIMap dropping all data - #40

Merged
Thrameos merged 1 commit into
masterfrom
backport/jni-map-value-dropped
Sep 6, 2026
Merged

Thrameos merged 1 commit into
masterfrom
backport/jni-map-value-dropped

Conversation

@Thrameos

@Thrameos Thrameos commented Sep 5, 2026

Copy link
Copy Markdown
Owner

Summary

  • 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 (GetCefValueFromJNIList) does this correctly via SetList().
  • Every Java Map ever passed to CefRequestContext.setPreference() silently lost all its data as a result.

Test plan

  • master already has CefRequestContextPreferencesTest.setPreferenceWithEachUnmappedJavaTypeDoesNotThrow() (landed via an earlier, unrelated backport), which exercises GetCefValueFromJNIMap via setPreference() -- it didn't catch this bug on its own since no settable dict/list preference exists to round-trip through and assert on directly, but the fixed code is what it now runs.
  • Rebuilt libjcef.so cleanly (ninja jcef), zero compile errors.
  • Full local suite run: 123/123 tests passing.

One-line, fully self-contained fix -- no new test file needed since master already has the exercising test. Same shape as PR #1, #36, #37, #38, #39.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq

@codecov

codecov Bot commented Sep 5, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 37.98%. Comparing base (be68fe1) to head (c4f83c3).

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #40      +/-   ##
============================================
- Coverage     38.01%   37.98%   -0.03%     
+ Complexity      735      732       -3     
============================================
  Files           243      243              
  Lines         14863    14864       +1     
  Branches       2449     2449              
============================================
- Hits           5650     5646       -4     
- Misses         8011     8012       +1     
- Partials       1202     1206       +4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

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.

Master already has CefRequestContextPreferencesTest's
setPreferenceWithEachUnmappedJavaTypeDoesNotThrow(), which exercises this
code path (added by an earlier, unrelated backport) but didn't catch this
bug since no settable dict/list preference exists to round-trip through.
Verified against a full local suite run: 123/123 passing.

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq
@Thrameos
Thrameos force-pushed the backport/jni-map-value-dropped branch from 93c99ee to c4f83c3 Compare September 5, 2026 21:23
@Thrameos Thrameos added the bug Something isn't working label Sep 6, 2026
@Thrameos
Thrameos merged commit 1a15fe3 into master Sep 6, 2026
9 checks passed
@Thrameos
Thrameos deleted the backport/jni-map-value-dropped branch September 6, 2026 03:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant