Browser e2e test disabled in the same commit that rewrote the code it covers, and two contradictory accounts of WebView.close()

[sroussey]

Defect

9a80450 fixed three real defects in providers/bun-webview/src/BunWebViewBackend.ts and rewrote the accessibility-tree walker in packages/browser-control/src/task/CDPBrowserBackend.ts — and in the same commit hard-disabled the only test that executes either of them.

examples/cli/src/test/browser-workflow.test.ts:50-52:

const WEBVIEW_CLOSE_REJECTS_UNCATCHABLY = true;

describe.skipIf(!chromeAvailable || WEBVIEW_CLOSE_REJECTS_UNCATCHABLY)(
  "Browser workflow end-to-end",

Executed at HEAD: npx vitest run examples/cli/src/test/browser-workflow.test.ts → Test Files 1 skipped (1) · Tests 1 skipped (1).

The skip is documented well — a named flag, a stated drop condition, and a docstring at :37-49 that credits the run for finding the three bugs. This issue is not about the skip being sloppy. It is about two consequences.

1. The commit gives two incompatible descriptions of WebView.close()

providers/bun-webview/src/BunWebViewBackend.ts:154-160:

Awaited, not fired and forgotten: close() reports an already-closed webview by REJECTING, and a rejection nobody is holding takes down the process rather than the call that caused it.

if (this._wv) await Promise.resolve(this._wv.close());

examples/cli/src/test/browser-workflow.test.ts:37-41:

Bun 1.4's WebView.close() returns undefined and then rejects a promise it keeps to itself: nothing here has a handle to catch it, and bun test fails whichever test is running on any unhandled rejection — a process.on("unhandledRejection") listener is not even called.

Both shipped in one commit; at most one can be right. If the second is the operative behaviour, await Promise.resolve(undefined) catches nothing, and the disconnect() change does not address the failure the test was disabled for — the fix and the disable are describing different bugs, and only one of them has been fixed.

2. The browser stack now has zero executing coverage anywhere

• packages/test/src/test/browser/BunWebViewBrowser.integration.test.ts and BunWebView_Generic.integration.test.ts are selected by no CI vitest job (re-measured at HEAD: 705 discovered, 694 CI-selected; see Test infrastructure: 21 CI-invisible test files, conformance-suite gaps, test tsconfig refs (audit §1.6 + Part 3 item 14) #701). package.json:44 excludes the browser section from test:vitest:integration and no dedicated job exists.
• packages/browser-control has zero co-located tests, and grep -rln "parseCDPAXTree\|queryAXTree" packages/test/src --include=*.test.ts returns nothing.
• browser-workflow.test.ts is now unconditionally skipped.

So after the window that rewrote both packages, nothing executes BunWebViewBackend or parseCDPAXTree. The next regression in either has no detector.

Proposed fix

1. Determine which account of close() is correct. If the rejection really is on a promise Bun keeps internally, the remedy is not in disconnect() — it is either a scoped unhandledRejection swallow in the test's afterEach, or not calling close() at all on a webview already known to be closed. Correct whichever docstring is wrong; a comment that misdescribes a third-party runtime is worse than none.
2. Re-enable the test, or replace it with a narrower one that exercises parseCDPAXTree against a recorded CDP Accessibility.getFullAXTree payload — that needs no webview at all and would have caught the subtree-dropping bug 9a80450 fixed.
3. Give the browser section a CI job (Test infrastructure: 21 CI-invisible test files, conformance-suite gaps, test tsconfig refs (audit §1.6 + Part 3 item 14) #701).

Why it matters

The three bun-webview fixes in this commit are good work — a connect() that threw "not connected — call connect() first" out of its own last step, an unhandled rejection that took down the process, and a bounded retry for a stale Bun navigation flag with the reasoning written at the site. Shipping them alongside the removal of the only thing that would catch their next regression is a net wash, and the review graded it that way.

Found during the 2026-08-31 review. Snapshot: workglow-dev/prd → analysis/grades/2026-08-31/libs-providers.md.