fix(cef): re-enable agent-control after disable + green CI (pin Flutter 3.38.8)#4
Merged
Conversation
Re-enabling agent-control on a previously-disabled tile hung: the 2nd per-browser Target.getTargetInfo probe never returned a targetId, so enableAgentControl timed out. cef_host's DoResolveTargetId reused a FIXED DevTools message id (kTargetInfoMsgId 0x7e57) on the browser's embedder DevTools session, and Chromium's session requires monotonically-increasing command ids — so the 2nd+ probe on the same browser was silently dropped. (Concurrent distinct browsers were fine: separate sessions.) Give each probe a fresh, increasing id (Slot::target_info_msg, seeded to kTargetInfoMsgId) and match the result against the slot's current id in the observer. Pairs with the already-landed resolveTargetId epoch guard so the resolve's stale 5s timer can't clobber the re-resolve. Restore the probe's re-enable lifecycle checks from a diagnostic to hard assertions. Verified live: 13/13 — re-enable yields a fresh grant, drives its own target again, the torn-down grant stays dead; probe completes in ~4s (was hanging ~25s). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…stable CI floated to `stable` (now 3.44.2), failing `flutter analyze` because the plugin's DeltaTextInputClient doesn't implement TextInputClient.onFocusReceived (a framework interface member added after 3.41). The package's consumer, work_canvas, ships on a custom 3.38.8 engine (its .fvmrc), so floating stable exercises a Flutter no consumer uses and breaks on every new interface method. Pin to 3.38.8 to test the real target. main's CI was already red on this before this branch. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
Two fixes to bring
mainto a healthy standalone state (follow-up to #3).1. Re-enable agent-control on a tile after disabling it (
cef_host)Re-enabling agent-control on a previously-disabled tile hung: the 2nd
per-browser
Target.getTargetInfoprobe never returned a targetId, soenableAgentControltimed out.DoResolveTargetIdreused a fixed DevToolsmessage id (
kTargetInfoMsgId 0x7e57) on the browser's embedder DevTools session,and Chromium requires monotonically-increasing command ids per session — so the
2nd+ probe on the same browser was silently dropped (concurrent distinct
browsers were fine: separate sessions).
Fix: a fresh, increasing id per probe (
Slot::target_info_msg), matched againstthe slot's current id in the observer. Pairs with the already-landed
resolveTargetIdepoch guard (#3) so the resolve's stale 5s timer can't clobberthe re-resolve.
Verified live — the two-view probe's re-enable lifecycle checks are now hard
assertions and pass (13/13): re-enable yields a fresh grant, drives its own target
again, the torn-down grant stays dead; the probe completes in ~4s (was hanging
~25s).
2. Pin CI to Flutter 3.38.8 (was floating
stable)main's CI was already red (pre-existing): floatingstable(3.44.2) failsflutter analyzebecause the plugin'sDeltaTextInputClientdoesn't implementTextInputClient.onFocusReceived(added after 3.41). The consumer (work_canvas)ships on a custom 3.38.8 engine, so stable tests a Flutter no consumer uses
and breaks on every new framework interface member. Pin CI to 3.38.8.
Still open (no code change here)
multi-tile multiplex works. Under a signed (
CEF_HOST_ADHOC=OFF)cef_host,Chromium's enforced Mach-port peer-validation only passes when the whole tree is
notarized (Developer-ID signing alone
-67030s locally). Confirm on anotarized Codemagic
macos-releasebuild. Low risk: the shipped release alreadypasses this for the single webview; P2's 2nd browser shares the same GPU process.
🤖 Generated with Claude Code