Spike: investigate scrolling and actionability gaps for `experimentalWebKitSupport`

[AtofStryker]

Summary

Child of #34870.

Three driver tests and one 8-test file are skipped on WebKit. They cover scroll-into-view and covered-element detection. There is also one open user-facing bug that matters more than all of them: #32031. The scaffolded 2-advanced-examples/actions.cy.js .click() test fails on WebKit, from 14.5.2 through 16.0.0. That spec is the first thing a new user runs.

None of these specs run on WebKit in our CI. #30770 (Jan 2025) narrowed the WebKit driver job's specPattern and left them out. The three skips were added together in #23232 (Aug 2022) with no diagnosis.

One more risk. visibilityStrategy now defaults to modern (#33794, May 2026) and uses Element.checkVisibility(). That code has never run on WebKit against an actions spec. Expect some currently-unguarded tests to fail too.

Related: #32031, #4233, #24815, #27046, #34869.

What's skipped

• packages/driver/cypress/e2e/commands/actions/check.cy.ts:243 — check a checkbox behind a position: sticky header inside a scrollable panel. Exercises ensureElIsNotCovered (packages/driver/src/cy/actionability.ts:199): elementFromPoint at center, then scroll each container past the covering element and retry. The skip cites Sticky elements within a fixed container are not properly taken into account when scrolling to an element #4233, which closed in Nov 2021 — a year before the skip. Treat it as having no recorded reason.
• packages/driver/cypress/e2e/commands/actions/selectFile.cy.ts:718 (can scroll to input) and :758 (scrollBehavior option). Both assertions sit on calls that fire unconditionally (actionability.ts:547-559), so they can't fail on their own — selectFile on the <input type="file"> itself must be failing. The unskipped siblings target the <label>. Likely one bug, not two.
• packages/driver/cypress/e2e/e2e/dom_hitbox.cy.ts:16 — whole file, 8 tests. The snapshot highlight overlay: content/padding/border layers within 1px of the target's box, elementFromPoint at the content center returns the content layer, click hitbox dot inside the target; covers inline elements, transform: scale/rotate, z-index. Same geometry stack (getElementPositioning, getCoordsByPosition, elementFromPoint) that cy.click() uses, so it's the cleanest probe for WebKit - click on a DOM element - scaffolded E2E test failure #32031. Skip links the PR that added the tests, not a diagnosis.

#32031. Failing line: cy.get('.action-labels>.label').click({ multiple: true }). WebKit reports the label is covered by <div class="arrow"> — the Bootstrap 3.3.6 popover arrow from the previous click. Screenshots on the issue show the popover is drawn misaligned in WebKit and aligned in Chrome/Firefox/Electron. So the covered check may be reporting the truth, and the question is why the popover is mispositioned: the example app's own layout (.label is display: inline; position: relative), or scroll/viewport state Cypress leaves behind. Don't guess — load https://example.cypress.io/commands/actions in plain playwright-webkit@1.61.0 with no Cypress and click the labels. If the popover is misaligned there too, it's an engine layout difference in the kitchensink, not an actionability bug.

Event dispatch is not the problem. Clicks are synthetic DOM events in every browser (packages/driver/src/cy/mouse.ts:775 el.dispatchEvent); WebKit automation has no mouse/keyboard handlers and never touches Playwright's page.mouse. There are no browser conditionals in actionability.ts, coordinates.ts, or visibility.ts. The one geometry admission in the suite is the coordsWebKit fork at click.cy.ts:3274-3292 — read it.

Adjacent, don't absorb: focus/blur (e2e/focus_blur.cy.js:517, own row); #24815 selectFile dataTransfer.items.add — probably unrelated since createDataTransfer runs on every selectFile and only two fail, but check its state; #27046 hardcoded 1280x720 — only relevant if a failure is viewport-dependent (check.cy.ts:243 opens with cy.viewport(400, 400); confirm that resizes the AUT in WebKit).

Method

1. Reproduce WebKit - click on a DOM element - scaffolded E2E test failure #32031 from the reporter's branch, then in-repo (packages/example/cypress.config.js has no experimentalWebKitSupport, so pass it):

   yarn cypress:run -- --project packages/example --browser webkit --config experimentalWebKitSupport=true --spec 'cypress/e2e/2-advanced-examples/actions.cy.js'
   

   Then the plain-Playwright comparison above.
2. Run the actions specs on WebKit, including the unguarded ones:

   cd packages/driver && yarn cypress:run --browser webkit --spec 'cypress/e2e/commands/actions/check.cy.ts,cypress/e2e/commands/actions/selectFile.cy.ts,cypress/e2e/e2e/dom_hitbox.cy.ts,cypress/e2e/commands/actions/click.cy.ts,cypress/e2e/commands/actions/scroll.cy.ts,cypress/e2e/commands/actions/trigger.cy.ts'
   

3. Remove the guards on a PoC branch; record what fails, with screenshots. Baseline each failure against Chrome on the same commit.

Non-goals

• Fixing anything.
• Focus/blur, cy.type() (Webkit has feature parity with other browsers with regard to keypress #31054), cy.origin() (Spike: investigate support for cy.origin() for experimentalWebKitSupport #34869).
• Changing the WebKit driver job's spec pattern — its own task on Spike (Parent): inventory of WebKit test gaps blocking GA for experimentalWebKitSupport #34870.
• iOS Safari.

Deliverables

• Per-test failure inventory with guards removed; Chrome pass/fail on the same commit.
• Root cause for WebKit - click on a DOM element - scaffolded E2E test failure #32031 backed by the plain-Playwright comparison: Cypress bug, kitchensink bug, or WebKit layout difference. If not a Cypress bug, what we tell users.
• Disposition per test: fix, document, or drop.
• Follow-ups per gap, sized. Fix or drop the stale Sticky elements within a fixed container are not properly taken into account when scrolling to an element #4233 reference at check.cy.ts:241.

Timebox

TBD after #32031 and the first driver run.