Spike: investigate support for `cy.origin()` for `experimentalWebKitSupport`

Summary

cy.origin() throws in WebKit today (packages/driver/src/cy/commands/origin/index.ts:37, error webkit.origin). Everything else about WebKit support is gated on this: we can't call the browser GA while the only sanctioned way to test cross-origin flows doesn't work in it, and we can't remove injectDocumentDomain (#30816) while WebKit users have no alternative (see the Auth0 deadlock described in #23799).

This spike is open-ended. The goal is a grounded answer to: what would it take to bring cy.origin() in WebKit to parity with Chrome and Firefox? Not to ship it.

Related: #23799 (the long-standing feature request), #30816 (injectDocumentDomain removal), #34298 (HTTP/2 WebKit spike, adjacent).

Areas to investigate

Each area should end with: what works today, what's missing, a rough size, and whether the gap is in our code, in Playwright's WebKit protocol, or in WebKit itself.

1. cy.origin() command and the spec bridge

• Remove the webkit.origin throw and run the packages/driver/cypress/e2e/e2e/origin/ suite (40 of 44 specs are currently { browser: '!webkit' }) to get a real failure inventory rather than a theoretical one.
• Spec bridge iframe creation, postMessage communicator, Cypress.require / dependency bundling inside the callback, snapshots, logging, uncaught-error surfacing from the bridge.
• Stack trace fidelity for errors thrown inside cy.origin() — WebKit already loses function names (stack_utils.ts:496); check whether the cross-origin remapping degrades further.

2. Code injection

• fullCrossOrigin injection is decided browser-agnostically (network-interception/lib/core/document-preparation.ts:28) and WebKit already marks the AUT frame via context.route('**') (webkit-automation.ts:150). Confirm injection actually lands in a cross-origin AUT document in WebKit and that Origin-Agent-Cluster / CSP nonce handling behaves.
• Confirm behavior with WebKit's process-swap-on-navigation: does the AUT frame survive a cross-origin navigation as the same Playwright Frame, or do we lose the handle?

3. Automation handlers WebKit lacks

• reload:aut:frame and navigate:aut:history are absent from WebKitAutomation.onRequest (webkit-automation.ts:387). cy.reload() and cy.go() currently sidestep them with window.location / history.go() precisely because there's no cy.origin() (navigation.ts:516, :596). Once the AUT can be cross-origin, the primary driver can no longer reach it that way; these need Playwright-backed implementations.
• reset:browser:state is a no-op in WebKit (webkit-automation.ts:412).
• webkit-cdp-bridge.ts supports only Runtime.enable/addBinding/evaluate and throws on everything else. Inventory which CDP-shaped calls the cross-origin path makes and whether Playwright's WebKit protocol can back them.

4. Cookies

• Cross-origin cookie jar, attach-cross-origin-cookies, copy-cookies-from-response, and simulated-top / SameSite handling are proxy-side and browser-agnostic. Verify they hold on the WebKit path (proxy-based network, not CDP Fetch).
• WebKit's ITP: does the Playwright WebKit build enforce third-party cookie blocking, cookie partitioning, or the 7-day cap on script-set cookies? Any of these changes what "parity" can mean.
• clearCookie/clearCookies clear everything and re-add survivors because Playwright has no filtered clear (webkit-automation.ts:294). There's an open FIXME that cookies aren't cleared properly between tests in headless WebKit (origin/cookie_misc.cy.ts). Cross-origin cookie tests need clean state to be meaningful.
• cy.session() cross-origin storage clearing (cookies, localStorage, sessionStorage per origin).

5. Test coverage and verification strategy

• Cypress-in-Cypress is not supported for WebKit (webkit.ts:45), so the cy-in-cy cy.origin error-UI system tests can't run. Decide how those behaviors get verified.
• Propose which of the skipped driver/system specs become the acceptance suite for a future implementation.

Non-goals

• Shipping cy.origin() in WebKit. Output is findings and follow-up issues.
• Test Replay / protocol support in WebKit (webkit.ts:48) — a GA dependency, but separate.
• HTTP/2 / native network path for WebKit — tracked in #34298.
• iOS Safari. This is desktop WebKit via playwright-webkit; nothing here addresses mobile Safari, and we should say so when we report back given Safari Mobile was the stated priority.

Deliverables

• Findings written up with the per-area breakdown above, including a PoC branch with the throw removed and the resulting failure inventory.
• A recommendation: feasible / feasible with caveats / not feasible on Playwright WebKit, with the caveats named.
• Follow-up issues for each distinct gap, sized.
• Anything blocked on Playwright or WebKit itself, with upstream links.

Timebox

TBD — propose after the first pass at area 1, since the failure inventory determines how deep the rest goes.