fix(webext)!: bridge tools to the inspected page

[SaKaNa-Y]

Important

Please take a moment to read this. Thank you!

I should include a brief explanation of the problem in my own words in every PR. If that explanation is missing, please @mention me and do not merge this PR until I have added it. You may also leave this PR unaddressed (because this means I have not fulfilled my responsibilities as the author).

If my explanation is unclear or difficult to follow, please ask me to clarify or provide reproduction steps or supporting evidence.

I welcome suggestions and counterarguments, especially questions about anything I may have overlooked. (Your feedback helps me learn and improve. 🙏)

I hold myself to this standard for every PR, regardless of its size.

Problem

Vue Tracer and A11y opened from the browser extension operate on the DevTools iframe instead of the inspected app. The extension boundary also defaults to JSON messaging, which changes typed-array and map values and rejects big integers and cyclic channel payloads.

Fix

Bind the Vite panel to chrome.devtools.inspectedWindow.tabId and the injected main-frame documentId. Relay page actions and in-page channel messages through dedicated ports, validating the panel window, origin, and session. Dispose stale connections on navigation and report unsupported page bridges explicitly.

Enable native structured-clone extension messaging to preserve channel payloads. The Chromium regression exercises the production isolated-world relay through real runtime ports and checks typed arrays, big integers, maps, sets, shared references, cyclic objects, dates, and blobs in a round trip. It fails with the previous manifest and passes with the updated configuration.

Breaking

The extension requires Chrome 148 or later, where native structured-clone messaging is supported. Upgrade Chrome before installing this extension version. The manifest enforces the minimum version, and the extension README documents it.

Merge and release order

1. Merge fix(devtools): clean up tracer activation subscriptions antfu/vite-plugin-vue-tracer#13 and publish a Tracer release containing the subscription fix.
2. Merge fix(hub-ui): bridge tools to the inspected page devframes/devframe#363 and publish the affected Devframe packages, including devframe, @devframes/hub, and @devframes/hub-ui.
3. Upgrade the dependencies used by fix(webext)!: bridge tools to the inspected page #563, validate the extension with both published fixes, then merge and release that adapter.

The first two fixes are independently mergeable and may be reviewed in parallel. The recommended order above puts the Tracer lifecycle fix first; the extension integration remains the final step. Published-package validation should include repeated Tracer activation, cancellation, and A11y inspection against the inspected app.

The dependency upgrades and validation against the required published packages remain pending. This PR follows the browser extension refactor in #530.

Verification

• pnpm lint, pnpm typecheck, and pnpm build: passed.
• pnpm test --run: 324 passed, 2 skipped, including 13 panel tests for binding, handshakes, forwarding, navigation cleanup, and unsupported bridges.
• pnpm -C packages/webext exec vue-tsc --noEmit and pnpm -C packages/webext build: passed.
• pnpm -C e2e exec vitest run tests/webext-inspected-page.test.ts: passed in Chromium using real extension messaging.
• Full Tracer/A11y UI end-to-end scenarios were not rerun in this revision; validation against the required published packages remains a release gate.

[pkg-pr-new]

Open in StackBlitz

@vitejs/devtools

npm i https://pkg.pr.new/@vitejs/devtools@563

@vitejs/devtools-kit

npm i https://pkg.pr.new/@vitejs/devtools-kit@563

@vitejs/devtools-oxc

npm i https://pkg.pr.new/@vitejs/devtools-oxc@563

@vitejs/devtools-rolldown

npm i https://pkg.pr.new/@vitejs/devtools-rolldown@563

@vitejs/devtools-vite

npm i https://pkg.pr.new/@vitejs/devtools-vite@563

@vitejs/devtools-vitest

npm i https://pkg.pr.new/@vitejs/devtools-vitest@563

commit: 8e370fb

[webfansplz]

Thanks for working on this! I think we should step back and discuss the runtime model before moving forward with this approach.

The underlying issue seems to be that plugins like Vue Tracer are initialized in both the in-page iframe and the Chrome DevTools panel. Ideally, the page-side logic would be initialized once per document, with both viewers connecting to that same runtime.

I think addressing this at its root requires starting with devframe/webext. I’ll start thinking through that design next (be related to devframes/devframe#329)

[SaKaNa-Y]

Thanks for pointing out the direction. I agree that we should pause for now.

Regarding your suggestion that the issue may stem from Vue Tracer being initialized in both the in-page iframe and the Chrome DevTools panel, the direct problem I’ve identified is that the inspection logic runs in the extension viewer’s document instead of the inspected application page. My approach in Devframe PR #363 and this PR is to add a communication bridge that forwards page-side operations from the extension to the existing embedded Hub in the inspected page.

However, considering #329, I understand that we need to address the problem at its root with a more general solution that extensions such as Vite DevTools can reuse.