[PR #813] [MERGED] fix(browser): distinguish WebMCP registration frame owners #2260

New issue

Closed

opened 2026-10-16 21:16:25 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:16:25 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/813
Author: @rudycelekli
Created: 10/7/2026
Status: ✅ Merged
Merged: 10/7/2026
Merged by: @N0zoM1z0

Base: main ← Head: fix/webmcp-frame-registration-identity-20261006

📝 Commits (1)

28eeb18 fix(browser): distinguish WebMCP registration frame owners

📊 Changes

6 files changed (+113 additions, -14 deletions)

View changed files

📝 docs/browser-observation.md (+1 -1)
📝 src/browser/CdpWebMcpDiscovery.ts (+3 -3)
📝 tests/boundary/browser/cdpBrowserProvider.document_script.test.ts (+48 -0)
📝 tests/fixtures/fakeCdpBrowserEvents.ts (+45 -0)
📝 tests/fixtures/fakeCdpBrowserResults.ts (+15 -10)
📝 tests/fixtures/fakeCdpBrowserTypes.ts (+1 -0)

📄 Description

Summary

Keep WebMCP registrations from distinct observed frames separate, including when their names and URLs match.

Problem and expected behavior

Two ordinary same-origin iframes serving the same URL can each register read_item. Actual Chrome154 emits two registrations with distinct frame IDs, but REA hashes only URL/name, retains one, and reports a complete inventory. Unregistering the retained second owner leaves the first registered in Chrome but REA returns zero. Passive discovery should retain both owners and remove only the requested owner. This is a reproduced ordinary bug fix, not a large contract change requiring an issue.

Change and scope

Include the observed frame ID in the registration identity. Same-frame updates retain one entry; updates and removals do not overwrite a different frame owner. Preserve current origin/frame admission, metadata parsing, and passive discovery. Owning docs explain that this key is not a stable identity across navigation or browser sessions.

Contract and boundary impact

Semantic owner and earliest changed stage: browser WebMCP registration normalization.
CLI and MCP/tool-catalog contract: same schemas and passive tool; registration keys now include observed frame ownership.
Provider, bridge, target-format, or platform compatibility: experimental Chrome CDP WebMCP inventory.
Evidence, artifact, provenance, or reconstruction contract: preserve separate observed registrations; no synthetic declarations or invocation.
Process execution, authorization, cleanup, or containment impact: none; existing origin and frame admission unchanged.
Generated metadata (docs/product-catalog.json), package, or installation impact: none.

Evidence and regression coverage

Tests added or updated: two existing-fixture protocol controls cover same-URL owners, same-frame updates and owner-specific removal. Both fail the base source;17existing controls pass.
Base reproduction or other evidence: actual public CdpBrowserProvider.discoverWebMcpTools, owned HTTP page and Chrome154. A transparent loopback CDP passthrough acknowledges the actual WebMCP.enable response before the external fixture registers tools. Traffic is forwarded unchanged; no synthetic protocol events. Independent native CDP events and document.modelContext.getTools() confirm the real registrations.
User-visible CLI/MCP output: the two-frame inventory reports2instead of1; unregistering the second leaves1instead of0. The single-frame control remains1.
Remaining proof gaps: no cross-browser or cross-navigation key stability claim. Chrome's initial child-frame replay behavior is unchanged; proof covers live registration events during the discovery window. The fixture tests supplement actual native producer evidence.
Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

Related document/script, capture comparison and browser MCP tests:29passed.
npm run check:5tasks passed,129existing warnings and zero errors.
npm run check:fast:2tasks passed.
npm run docs:check and npm run build:passed.
Actual owned Chrome154 passive discovery: single, duplicate-URL two-frame, unregister-second controls passed.
Full npm run verify:browser:passed, including existing public CLI/stdio MCP, popup, network, screenshot and script-export workflows. Its existing descendant-run-token mismatch reports process-lineage evidence unavailable; no stronger lineage claim.

Compatibility, safety, and release

Breaking changes or migration steps: no schema changes; tool key values now identify observed frame ownership.
Real Hopper/Ghidra, browser, or OS coverage: actual Chrome154/macOS only.
Package or release metadata impact: none.
Security, privacy, process, or containment review: no admission or invocation changes; owned loopback fixture only. REA does not evaluate or invoke page code. The external test harness registers/unregisters its own fixture tools.

Review checklist

The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

AI-assisted implementation and verification; I reviewed the patch and ran the reported checks.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/813 **Author:** [@rudycelekli](https://github.com/rudycelekli) **Created:** 10/7/2026 **Status:** ✅ Merged **Merged:** 10/7/2026 **Merged by:** [@N0zoM1z0](https://github.com/N0zoM1z0) **Base:** `main` ← **Head:** `fix/webmcp-frame-registration-identity-20261006` --- ### 📝 Commits (1) - [`28eeb18`](https://github.com/morluto/rea/commit/28eeb18ed5171def470f0badd98e548a93c1d9f4) fix(browser): distinguish WebMCP registration frame owners ### 📊 Changes **6 files changed** (+113 additions, -14 deletions) <details> <summary>View changed files</summary> 📝 `docs/browser-observation.md` (+1 -1) 📝 `src/browser/CdpWebMcpDiscovery.ts` (+3 -3) 📝 `tests/boundary/browser/cdpBrowserProvider.document_script.test.ts` (+48 -0) 📝 `tests/fixtures/fakeCdpBrowserEvents.ts` (+45 -0) 📝 `tests/fixtures/fakeCdpBrowserResults.ts` (+15 -10) 📝 `tests/fixtures/fakeCdpBrowserTypes.ts` (+1 -0) </details> ### 📄 Description ## Summary Keep WebMCP registrations from distinct observed frames separate, including when their names and URLs match. ## Problem and expected behavior Two ordinary same-origin iframes serving the same URL can each register `read_item`. Actual Chrome154 emits two registrations with distinct frame IDs, but REA hashes only URL/name, retains one, and reports a complete inventory. Unregistering the retained second owner leaves the first registered in Chrome but REA returns zero. Passive discovery should retain both owners and remove only the requested owner. This is a reproduced ordinary bug fix, not a large contract change requiring an issue. ## Change and scope Include the observed frame ID in the registration identity. Same-frame updates retain one entry; updates and removals do not overwrite a different frame owner. Preserve current origin/frame admission, metadata parsing, and passive discovery. Owning docs explain that this key is not a stable identity across navigation or browser sessions. ## Contract and boundary impact - Semantic owner and earliest changed stage: browser WebMCP registration normalization. - CLI and MCP/tool-catalog contract: same schemas and passive tool; registration keys now include observed frame ownership. - Provider, bridge, target-format, or platform compatibility: experimental Chrome CDP WebMCP inventory. - Evidence, artifact, provenance, or reconstruction contract: preserve separate observed registrations; no synthetic declarations or invocation. - Process execution, authorization, cleanup, or containment impact: none; existing origin and frame admission unchanged. - Generated metadata (`docs/product-catalog.json`), package, or installation impact: none. ## Evidence and regression coverage - Tests added or updated: two existing-fixture protocol controls cover same-URL owners, same-frame updates and owner-specific removal. Both fail the base source;17existing controls pass. - Base reproduction or other evidence: actual public `CdpBrowserProvider.discoverWebMcpTools`, owned HTTP page and Chrome154. A transparent loopback CDP passthrough acknowledges the actual `WebMCP.enable` response before the external fixture registers tools. Traffic is forwarded unchanged; no synthetic protocol events. Independent native CDP events and `document.modelContext.getTools()` confirm the real registrations. - User-visible CLI/MCP output: the two-frame inventory reports2instead of1; unregistering the second leaves1instead of0. The single-frame control remains1. - Remaining proof gaps: no cross-browser or cross-navigation key stability claim. Chrome's initial child-frame replay behavior is unchanged; proof covers live registration events during the discovery window. The fixture tests supplement actual native producer evidence. - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - Related document/script, capture comparison and browser MCP tests:29passed. - `npm run check`:5tasks passed,129existing warnings and zero errors. - `npm run check:fast`:2tasks passed. - `npm run docs:check` and `npm run build`:passed. - Actual owned Chrome154 passive discovery: single, duplicate-URL two-frame, unregister-second controls passed. - Full `npm run verify:browser`:passed, including existing public CLI/stdio MCP, popup, network, screenshot and script-export workflows. Its existing descendant-run-token mismatch reports process-lineage evidence unavailable; no stronger lineage claim. ## Compatibility, safety, and release - Breaking changes or migration steps: no schema changes; tool key values now identify observed frame ownership. - Real Hopper/Ghidra, browser, or OS coverage: actual Chrome154/macOS only. - Package or release metadata impact: none. - Security, privacy, process, or containment review: no admission or invocation changes; owned loopback fixture only. REA does not evaluate or invoke page code. The external test harness registers/unregisters its own fixture tools. ## Review checklist - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. AI-assisted implementation and verification; I reviewed the patch and ran the reported checks. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:16:25 +00:00