[webkit] Sub-resource requests timeout through Cypress proxy causing Vue app not to mount and cy.session() restore to hang in Cypress 15.15.0

[soni09bhatia]

Current behavior

Cypress Version
15.15.0

Browser
webkit

Using:
experimentalWebKitSupport: true

and:
playwright-webkit@1.60.0

Operating System

Local
Windows 10
CI
Ubuntu (Azure DevOps Linux agent)

Node / pnpm Versions
Node: 20.16.0
pnpm: 10.33.0

Description
After upgrading to Cypress 15.x (confirmed on 15.15.0), all tests running in WebKit fail consistently while the same specs pass successfully in Chrome.
The initial HTML document loads successfully (HTTP 200), however the Vue application never mounts because all subsequent sub-resource requests (JS bundles, CSS assets, and Cypress socket connections) timeout through the Cypress proxy.
This results in:
Blank white page
Vue application never mounting
cy.session() restore hanging indefinitely
Subsequent command timeouts cascading through the suite
Chrome execution using the same configuration, specs, infrastructure, and environment works without issue.

Observed Console Errors
Failed to load resource: Timeout was reached

→ https:///bundles/acresi-vue-library/v=
→ https:///bundles/css-layer-order?v=
→ https:///bundles/libraries-css?v=
→ https:///bundles/common/content/common-css?v=
→ https:///bundles/main/content/main-css?v=
→ https:///acresi-vue-library/dist/assets/third-party-css?v=

→ https:///__socket/?EIO=4&transport=polling&t=
Followed by:
Failed to load resource: the server responded with a status of 404

→ https:///__socket/?EIO=4&transport=polling&sid=

→ https:///__cypress/runner/escape.js.map

Important observation:
The initial HTML document request succeeds (200)
Only sub-resource requests fail
Chrome is unaffected
WebKit consistently reproduces the issue

Steps to Reproduce

Enable experimentalWebKitSupport
Use cy.session() inside beforeEach
Register multiple cy.intercept() routes
Execute cy.visit('/Dashboard')
Run the spec using:
cypress run --browser webkit

Expected Behavior
Vue application mounts successfully
JS/CSS bundles load normally
cy.session() restore completes
Tests execute successfully

Actual Behavior
Initial HTML document loads
All subsequent JS/CSS/socket requests timeout
Vue never mounts
Blank white page displayed
cy.session() hangs indefinitely
Tests fail with cascading timeout errors

Failure Modes
Failure 1 — Application Never Renders
AssertionError: Timed out retrying after 20000ms:
Expected to find element: [data-cy="nav-care-network"], but never found it.
Cause:
Main Vue bundle request times out, preventing the application from mounting.

Failure 2 — cy.session() Restore Hangs
CypressError: cy.then() timed out after waiting 20000ms.
Your callback function returned a promise that never resolved.
Stack trace points to:
async () => {
setSessionLogStatus(...SESSION_STEPS.restore));
await navigateAboutBlank();
await sessions.clearCurrentSessionData();
return restoreSession(existingSession);
}
Cause:
Cypress internal __socket polling requests timeout, causing browser communication loss during session restore.

Failure 3 — Cascading Mocha Hook Error
Error: done() called multiple times in hook
This appears to occur after the session restore timeout triggers cleanup logic while the original hook completion is still pending.

Cypress Configuration
module.exports = defineConfig({
chromeWebSecurity: false,
defaultCommandTimeout: 20000,
pageLoadTimeout: 100000,
responseTimeout: 60000,
requestTimeout: 30000,
experimentalSourceRewriting: false,
experimentalWebKitSupport: true,
testIsolation: false,

retries: {
runMode: 1,
openMode: 1,
},
});

Investigation Performed

<style> </style>

Investigation	Result
Different playwright-webkit versions	Reproduced on multiple versions
CSP / third-party script rewriting	Not the cause
experimentalSourceRewriting	No impact
Authentication / cookies	Login succeeds correctly
Cross-origin resource blocking	All requests are same-origin
App-side JS exceptions	No uncaught exceptions detected
CI resource starvation	Ruled out
Azure agent scaling issues	Ruled out

Key Observation
WebKit attempts to resolve Cypress assets against the application origin:
https:///__cypress/runner/escape.js.map
instead of resolving them through the Cypress proxy origin. This suggests a possible WebKit-specific proxy/origin resolution issue affecting Cypress-injected resources and socket communication.

Suspected Root Cause

The Cypress 15.x proxy layer appears unable to properly maintain sub-resource forwarding and internal socket communication in WebKit after the initial HTML document is served.
The issue appears specifically related to Cypress internal stability handling combined with broken WebKit socket communication.

Related Cypress PR — Potential Regression Source
Reference PR:
#33446 - #33446
“fix: prevent hang when waiting on multiple intercepts and navigating”
Released in:
Cypress 15.12.0

What PR #33446 Changed
PR #33446 modified Cypress’s internal stability handling logic.
Previously, Cypress stored a single whenStable callback. Multiple registrations would overwrite previous callbacks.
The fix replaced this with a queue-based implementation:
whenStableQueue.push(fn)
which later releases all waiters during:
isStable(true)
This behavior is correct and improves stability handling in Chrome.

Why This Appears to Regress WebKit
In WebKit, Cypress internal Socket.IO polling requests appear unable to establish reliably through the Cypress proxy:
Failed to load resource: Timeout was reached
→ /__socket/?EIO=4&transport=polling&t=
followed by:
Failed to load resource: 404
→ /__socket/?EIO=4&transport=polling&sid=
These socket failures appear to prevent Cypress from ever reaching a stable state in WebKit.

Behavioral Difference Before vs After 15.12.0

<style> </style>

Scenario	Pre-15.12.0	Post-15.12.0
WebKit socket connection fails	One waiter could still escape due to callback overwrites	All waiters remain queued
isStable(true) resolution	Occasionally/unreliably triggered	Never triggered
Result	Flaky but partially functional execution	Complete deadlock and global timeout behavior

Before the queue implementation, the overwrite behavior unintentionally allowed some commands to continue executing even when stability signaling was degraded.
After the queue-based fix, all commands correctly wait for stability resolution. However, because WebKit never appears to reach a stable state once the internal __socket connection fails, the queue is never released.

This results in:

• cy.visit() completing only for the initial HTML document
• All subsequent JS/CSS sub-resource requests hanging
• Vue never mounting
• cy.session() restore hanging indefinitely
• Global command timeouts cascading through the suite

Why This Matches Our Test Setup
Our beforeEach hooks register multiple cy.intercept() routes through page object routes() methods.
This creates multiple stability waiters during every test initialization cycle, which aligns directly with the queue-based logic introduced in PR #33446.
Because the queue never resolves in WebKit once socket communication fails, every waiter remains blocked permanently.

Additional Context
The PR itself was marked internally as:
“Medium Risk — Changes core driver stability/wait logic used by retries and command execution, which could affect timing/order of command release in edge cases.”
This WebKit proxy/socket scenario appears consistent with that class of edge case.

Suggested Investigation Areas
Potential areas worth investigating:

1. WebKit-specific handling of Cypress internal __socket polling
2. Stability resolution dependency on Socket.IO connectivity
3. Proxy/origin handling for Cypress-injected resources in WebKit
4. Adding fallback stability resolution behavior when socket connectivity fails
5. WebKit-specific timeout/recovery path for whenStableQueue
6. The issue appears reproducible specifically on remote HTTPS domains running through the Cypress proxy in WebKit.

Current Workaround
Affected tests are currently skipped in WebKit to avoid CI instability:
if (Cypress.isBrowser('webkit')) {
this.skip();
}

Additional Notes

1. Issue did not occur prior to upgrading to Cypress 15.x
2. Chrome execution remains fully stable
3. Reproduced both locally and in CI
4. CI runs in isolated infrastructure
5. WebKit stage runs independently in its own scaling pool
6. Resource contention does not appear to be a contributing factor
7. The same WebKit test suite worked successfully on Cypress 15.7.0
8. The issue started immediately after upgrading from 15.7.0 to 15.15.0
9. No application-side changes were introduced alongside the Cypress upgrade
10. This strongly suggests a regression introduced somewhere between Cypress 15.7.0 and 15.15.0

InvestigationPerformed.xlsx

Desired behavior

Expected Behavior**
Vue application mounts successfully
JS/CSS bundles load normally
cy.session() restore completes
Tests execute successfully

Test code to reproduce

Cypress Version

15.15.0

Debug Logs

Other

No response

[mschile]

Hi @soni09bhatia, thanks for logging this issue. Unfortunately, it's difficult to parse through your issue description. Could you please ensure it is following our issue template.

Related Cypress PR — Potential Regression Source
Reference PR:
#33446 - #33446
“fix: prevent hang when waiting on multiple intercepts and navigating”
Released in:
Cypress 15.12.0

You mention that you believe the issue started in 15.12.0 but I don't see that you've verified this. Did you test in 15.11.0 and it passed and then in 15.12.0 is started failing?

Steps to Reproduce

Enable experimentalWebKitSupport
Use cy.session() inside beforeEach
Register multiple cy.intercept() routes
Execute cy.visit('/Dashboard')
Run the spec using:
cypress run --browser webkit

Unfortunately, I cannot reproduce the issue with these steps. Please provide a reproducible example of the issue you're encountering. Forking Cypress Test Tiny makes sharing a reproducible example easier to share and easier for our engineers to replicate your issues. This method also keeps the reproduction as simple as possible, which helps us eliminate potential causes and noise from the investigation.

[soni09bhatia]

Hi @mschile , please find the ticket description as per your template -

Current behavior

After upgrading Cypress from 15.7.0 to 15.15.0, WebKit tests consistently fail while Chrome tests continue to pass successfully under the same environment and configuration.

The initial HTML document loads successfully (HTTP 200), however all subsequent sub-resource requests timeout in WebKit, including:

Vue JS bundles
CSS assets
Cypress internal __socket polling requests

As a result:

The Vue application never mounts
The page remains blank white
cy.session() restore hangs indefinitely
Cypress commands eventually timeout
Mocha hook failures cascade afterward

Observed WebKit console errors:

Failed to load resource: Timeout was reached

→ /bundles/acresi-vue-library/v=
→ /bundles/css-layer-order?v=
→ /bundles/libraries-css?v=
→ /__socket/?EIO=4&transport=polling&t=

Followed by:

Failed to load resource: 404

→ /__socket/?EIO=4&transport=polling&sid=
→ /__cypress/runner/escape.js.map

Key observations:

Chrome is unaffected
Issue reproduces locally and in CI
All resources are same-origin
Login/authentication succeeds correctly
No uncaught application exceptions are observed

The issue appears related to Cypress stability handling introduced around 15.12.0, specifically PR #33446 (whenStableQueue stability changes), combined with failing WebKit socket communication.

WebKit appears unable to establish Cypress internal __socket polling connections, preventing isStable(true) from ever resolving. As a result, all queued stability waiters remain blocked indefinitely.

Desired behavior

WebKit execution should behave consistently with Chrome:

JS/CSS sub-resources should load successfully
Cypress internal socket communication should establish normally
Vue application should mount correctly
cy.session() restore should complete successfully
Stability waiters should resolve correctly
Tests should execute without hanging or timing out

Run command:

cypress run --browser webkit

Cypress Version

Working version:

15.7.0

Broken version:

15.15.0

Potential regression introduced around:

15.12.0

Browser:

webkit

Additional packages:

playwright-webkit@1.60.0

Environment:

Windows 10 (local)
Ubuntu Azure DevOps agents (CI)

Node:
20.16.0

pnpm:
10.33.0

Debug Logs

Application never mounts due to timed out sub-resource requests.

Primary failures:

AssertionError: Timed out retrying after 20000ms:
Expected to find element: [data-cy="nav-care-network"], but never found it.
CypressError: cy.then() timed out after waiting 20000ms.
Your callback function returned a promise that never resolved.

Related stack trace:

async () => {
await navigateAboutBlank();
await sessions.clearCurrentSessionData();
return restoreSession(existingSession);
}

Additional cascading error:

Error: done() called multiple times in hook

WebKit console/network errors:

Failed to load resource: Timeout was reached
→ /__socket/?EIO=4&transport=polling&t=
Failed to load resource: 404
→ /__socket/?EIO=4&transport=polling&sid=

Other

Relevant Cypress PR:

#33446
“fix: prevent hang when waiting on multiple intercepts and navigating”

Why this appears related:

1. Prior to 15.12.0, Cypress used a single whenStable callback
2. After 15.12.0, Cypress introduced a queue-based whenStableQueue
3. In WebKit, failed socket communication appears to prevent isStable(true) from ever firing
4. This causes all queued waiters to remain blocked indefinitely

Additional notes:

1. Chrome execution remains fully stable
2. CI infrastructure/resource starvation has been ruled out
3. Issue reproduces both locally and in CI
4. WebKit tests are currently skipped in CI as a temporary workaround

[soni09bhatia]

Regarding the below statement -

"You mention that you believe the issue started in 15.12.0 but I don't see that you've verified this. Did you test in 15.11.0 and it passed and then in 15.12.0 is started failing?"

We have not yet done a precise version-by-version bisect between 15.7.0 and 15.15.0, so I cannot conclusively say that 15.12.0 is the exact first broken version.

What we have verified so far is:

WebKit tests were running successfully on 15.7.0
After upgrading directly to 15.15.0, WebKit execution started failing consistently
Chrome execution remained stable throughout

The reason we referenced 15.12.0 specifically is because, during investigation, PR #33446 stood out as a potentially relevant architectural change to Cypress’s internal stability handling (whenStableQueue changes). The behavior introduced there aligns closely with what we are observing in WebKit:

Cypress internal __socket polling requests fail in WebKit
isStable(true) appears to never resolve
queued stability waiters remain blocked indefinitely
subsequent JS/CSS sub-resource requests hang
Vue never mounts and cy.session() restore hangs

So at this stage, 15.12.0 is a suspected regression window based on code-path correlation, not a fully verified first-failing version.

We have not yet validated:

15.11.0 passes
15.12.0 fails

[mschile]

@soni09bhatia, running the spec you provided passes for me in WebKit. Does it fail for you?

[soni09bhatia]

@cacieprins @mschile

Update — issue is reproducible with a production-equivalent spec

I've added a more complete reproduction to the cypress-test-tiny repo on the branch fix/webkit-33926-subresouce-timeout-session-hang (cypress-io/cypress-test-tiny@c4e9abd) that closely mirrors our actual acresi-cypress-v2 configuration.

What was added:

• cypress/e2e/verify-no-scripting-error-and-residents-grid-layout-in-ipad.cy.js — the spec that reproduces the issue, matching our production test structure
• Full supporting layer: page objects (DashBoardPage, ClientsPage), device-utils.js (multi-viewport iteration via testAcrossWebTabletViewports), login.js, feature flags, and fixtures
• cypress.config.js updated to match our production config: baseUrl, testIsolation: false, failOnStatusCode: false, experimentalSourceRewriting: false

Key factors that trigger the regression (absent from the earlier minimal repro):

1. cy.login() in beforeEach — uses cy.session(), triggering the restore path where internal __socket polling hangs
2. DashBoardPage.routes() + ClientsPage.routes() each register multiple cy.intercept() calls — creates multiple stability waiters in the queue introduced by PR fix: prevent hang when waiting on multiple intercepts and navigating #33446
3. A Vue application with heavy JS/CSS bundles loading through the Cypress WebKit proxy
4. Multiple viewports iterated via testAcrossWebTabletViewports — the hang occurs on the second viewport and beyond

The spec passes successfully in Chrome. In WebKit, sub-resource requests timeout, Vue never mounts, and the test suite deadlocks exactly as described in the original report.

Happy to provide any additional details or run specific diagnostic builds if that would help narrow down the fix.

[cacieprins]

Hi @soni09bhatia , this reproduction expects access (and credentials) for your environment. Maybe you can get in touch with your support engineer to coordinate these sensitive values?

You could also try mocking the server requests/responses, but that may leak too much information publicly. Feel free to send us a private fork if so. As is, we still cannot reproduce this unfortunately.

[soni09bhatia]

@cacieprins - I noticed you're making changes in this PR — #33934 — which seems related to the open issue. Were you able to reproduce the problem and are now working on a fix for it, or are these more general WebKit-related improvements connected to the previous work done in #33446?

[soni09bhatia]

Hi @cacieprins , we'd like to help by providing private access to our environment. Due to internal security policy we can't share credentials or URLs publicly. We have a paid Cypress account — could you share a secure way to send you the reproduction details privately? We're happy to use a private GitHub fork, email, or whatever channel works best for you. Please let us know how to proceed.