Repository navigation
Add CefFindHandler binding (GH #32) - #51
Merged
Merged
Conversation
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.
Add native/find_handler.{h,cpp} + org.cef.handler.CefFindHandler, wired
into client_handler.cpp/CefClient the same way every other handler type
is (DragHandler is the closest existing pattern, using this branch's own
GetHandler<T>() template rather than the future branch's older direct-
lookup style).
Backport of coverage/phase1-value-objects-phase2-handlers' 135dc98,
with JCEF_TRACE calls dropped (not on master) and a fresh, minimal
CefFindHandlerTest.java instead of modifying the existing
CefBrowserApiTest.java (which has diverged significantly on the future
branch's coverage work) -- exercises CefBrowser.find()/onFindResult()
directly. Bounded with assertTimeoutPreemptively(20s) rather than the
usual blind TestFrame.awaitCompletion(): this is the first test here
exercising find()'s actual async round-trip, and CefDevToolsClient.
executeDevToolsMethod() (a different CEF subsystem) is a confirmed
unrecoverable hang in this environment (issue #12) -- fail cleanly on a
timeout rather than risk blocking the whole suite if find() turns out to
have a similar issue here.
Verified: full clean rebuild (native via a fresh cmake reconfigure to
pick up the new find_handler.cpp/.h sources, + Java), CefFindHandlerTest
passes in ~2s (no hang). A post-summary "Aborted (core dumped)" crash
after the JUnit run reported 0 failures is the already-tracked,
pre-existing GH #10 shutdown-race SIGSEGV, unrelated to this change.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #51 +/- ##
============================================
+ Coverage 38.01% 38.17% +0.16%
- Complexity 735 741 +6
============================================
Files 243 246 +3
Lines 14863 14930 +67
Branches 2449 2460 +11
============================================
+ Hits 5650 5700 +50
- Misses 8011 8013 +2
- Partials 1202 1217 +15 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
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.native/find_handler.{h,cpp}+org.cef.handler.CefFindHandler/CefFindHandlerAdapter, wired intoclient_handler.cpp/CefClientthe same way every other handler type is (DragHandleris the closest existing pattern, using this branch's ownGetHandler<T>()template).coverage/phase1-value-objects-phase2-handlers'135dc98, withJCEF_TRACEcalls dropped (not on master) and a fresh, minimalCefFindHandlerTest.javainstead of modifying the existingCefBrowserApiTest.java(which has diverged significantly on the future branch's coverage work).Test plan
cmakereconfigure to pick up the newfind_handler.cpp/.hsources, +ninja, +tools/compile.sh)CefFindHandlerTestexercisesCefBrowser.find()/onFindResult()directly, bounded withassertTimeoutPreemptively(20s)rather than the usual blindTestFrame.awaitCompletion()-- this is the first test here exercisingfind()'s actual async round-trip, and a different CEF subsystem (CefDevToolsClient.executeDevToolsMethod()) is a confirmed unrecoverable hang in this environment (issue CefBrowser.getDevToolsClient()/executeDevToolsMethod() and browser.print() can hang indefinitely, unrecoverable #12), so this fails cleanly on a timeout instead of risking the whole suite🤖 Generated with Claude Code
https://claude.ai/code/session_01HBFmQs6JDypYP5qdC99yDq