[liuhedev]

A CSP-blocked auxiliary iframe can become a Chrome-owned chrome-error://chromewebdata/ document. That document cannot host the cooperation content script, but collectCooperationFrames still waits for its receiver. One rejected tabs.sendMessage then makes shared control unavailable for the entire tab.

This proposes retaining a stable identity for independently verified browser-error subframes instead of waiting for an impossible content-script response. It cross-checks the CDP frame tree with the WebNavigation snapshot and rechecks the document identity before accepting the fallback. Main-frame failures, ambiguous matches, ordinary web frames with missing receivers, and malformed responses still fail closed. No extension permissions or protocol changes are included.

Reproduction

1. Serve a page with an editable input and an iframe whose navigation is blocked by the page's frame-src CSP.
2. Confirm that Chrome exposes the failed child as chrome-error://chromewebdata/.
3. Run bsk cooperate sync after the page settles.
4. The current release reports “Receiving end does not exist” and cannot control the otherwise usable parent page.

Validation

• pnpm --filter @browser-skill/extension compile: passed.
• Existing browser-bridge.test.ts and controller.test.ts suites: 196 tests passed.
• pnpm ext:build: passed.
• Extension permissions and content-script declarations are unchanged.

A live comparison now confirms the failure and the proposed fix using the same minimal fixture, Chrome for Testing 151.0.7922.34, CLI 0.4.0, and protocol 1.7. Each build runs in a fresh isolated profile, against a dedicated local daemon. The package's default daemon endpoint alone is redirected to that test daemon; shared-control guards remain enabled.

Fixture	Released ext-v0.4.0	Patched dsh-plugin-v0.4.0-1-g05116e5
Parent form, no iframe	ready; fill/click and output readback passed	ready; fill/click and output readback passed
Same form with a normal child iframe	ready; fill/click and output readback passed	ready; fill/click and output readback passed
Same form and iframe with Content-Security-Policy: frame-src 'none'	unavailable; no action context issued	ready; fill/click and output readback passed

The normal and CSP-blocked responses serve identical parent HTML and the same iframe URL; only the CSP response header differs. For every successful action case, the parent input is filled, Apply is clicked through BSK using fresh contexts, and the actual <output> value is read back from the page HTML.

Remaining scope: the minimal browser regression passes, but the patched extension has not yet been accepted on the affected real-world page in the user's logged-in browser. The existing unit suites alone do not cover the new browser-error fallback; the result above is live integration evidence.

[liuhedev]

Could a maintainer approve the pending CI runs and review this fix? The released and patched builds were compared using the same Chrome version and minimal CSP-blocked iframe fixture. The patch restores parent-page control while retaining document identity checks. Validation details are included in the PR description.