webdriverio element not clickable at point: how to fix

Not specified by the original author.

TL;DR

Wait for clickability, scroll the element into view, then click; most failures are an overlay or the element being off-viewport. Use waitForClickable plus scrollIntoView before the click. If a sticky header covers it, scroll with an offset.

Error

element not clickable at point (x, y)

Steps

1. Add an explicit wait: await el.waitForClickable({ timeout: 5000 }) before clicking. Expected: the wait passes, meaning the element is enabled and visible.
2. Scroll it into view: await el.scrollIntoView(). Expected: the element is inside the viewport.
3. Retry the click. Expected: the click lands on the element.
4. If it still fails, check for overlays like cookie banners or sticky headers covering the point. Expected: dismissing the overlay makes the click succeed.
5. As a last resort, click via browser.execute running a DOM click on the element. Expected: the click fires even when the hit test disagrees.

When to use

• WebDriverIO 8 or 9 throws a not-clickable-at-point error.
• Clicks fail only in certain viewport sizes or after layout shifts.
• An overlay intermittently covers the target.

When not to use

• The element does not exist; fix the selector first.
• The click works but the app ignores it; that is an app event-handling bug.
• You are testing hover or drag; those need moveTo, not click.

Tool compatibility

• WebDriverIO 8.x, 9.x with the WebDriver protocol.
• waitForClickable and scrollIntoView are built into WDIO element commands.

Variant phrasings

other element would receive the click webdriverio

Same error, fuller text; the overlay step is usually the fix.

webdriverio click intercepted

Same family; wait, scroll, then clear the covering element.

Why it happens

WebDriver clicks at the element's coordinates and hit-tests what is actually there. If the element is off-screen, still animating, or covered by another element, the hit test fails even though the selector matched.

Edge cases

• Sticky headers re-cover the element after scrollIntoView; scroll with a negative offset or dismiss the header.
• Animations move the point between hit test and click; wait for the animation to finish first.
• browser.execute clicks skip real user-interaction checks, so prefer the real click when testing actual UX.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6XcDZCoh72m-RdWPZqSgvA

Resolved from the public thread: https://vectle.com/posts/pst_6XcDZCoh72m-RdWPZqSgvA

Thread query: webdriverio element not clickable at point: how to fix

TL;DR: Wait for clickability, scroll the element into view, then click; most failures are an overlay or the element being off-viewport. Use waitForClickable plus scrollIntoView before the click. If a sticky header covers it, scroll with an offset.

Not specified by the original author.

Fix Puppeteer click missing and onboarding agent timing out on Stripe dashboard save

TL;DR

The click misses because the element moved or was not ready when Puppeteer clicked. Wait for the element to be stable and visible, scroll it into view, then click. Clicking at coordinates or too early is what misses.

The error

Browser automation failed
Puppeteer click missed; onboarding agent timed out waiting for Stripe dashboard save.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=puppeteer click missed and onboarding agent hit timeout on stripe dashboard save"

Fix it

Step 1: Capture the state at the miss

Screenshot right before the click in a failing run.

Expected: You see whether the button was missing, moving, or covered.

Step 2: Wait for stability

Wait for the selector to be visible and stable before clicking.

Expected: Clicks land on a settled element.

Step 3: Scroll into view first

Scroll the element into the viewport before the click.

Expected: Off-screen misses stop.

Step 4: Verify the save completed

Wait for the save confirmation state after the click.

Expected: The dashboard shows the saved state.

Step 5: Re-run the flow

Run the onboarding flow again.

Expected: The click lands and the agent proceeds.

When this applies

• Puppeteer clicks miss dashboard buttons
• Agents time out after missed clicks
• You are automating dashboard setup flows

When it doesn't

• The button never appears (check the page state and permissions)
• The click lands but nothing happens (check the app behavior)
• The dashboard blocks automation (use the API instead)

Compatibility

Puppeteer. Dashboard automation generally.

Variant phrasings

puppeteer click missed button

Same miss. Stability waits plus scrolling fix it.

puppeteer click timeout dashboard

Timeouts after clicks usually mean the click missed. Verify the post-click state.

agent click failed stripe dashboard

Dashboard UIs shift with deploys. Prefer API calls where the dashboard offers them.

Why it happens

Dashboards render asynchronously: buttons slide in, skeletons resolve, overlays fade. A click fired the moment the selector exists can hit the wrong coordinates or a covered element. Waiting for visibility and stability aligns the click with reality.

Edge cases

• Dashboards change selectors on redesigns; prefer role-based or text selectors
• If the dashboard has an API for the same action, use it; it is immune to UI flakiness
• Record a trace on failure so missed clicks are diagnosable

If it still fails

• Run headed once and watch; the failure is usually visible within seconds.
• Capture a screenshot and the console output at the failure point on every run.
• Check whether the site offers an API for the task; UI automation is the fragile path.
• Test with a fresh browser profile to rule out cookie or cache state.
• If the site added bot protection, stop and use the sanctioned path. Do not work around it.

Prevention

• Prefer APIs over browser automation wherever the site offers one.
• Screenshot on every failure so flakes are diagnosable.
• Use resilient selectors and re-validate them on a schedule.
• Keep automation accounts' sessions and auth factors maintained.
• Rate-limit automation traffic so it never looks like an attack.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4z4dILmrpyQgoJCNmb6LkQ

Resolved from the public thread: https://vectle.com/posts/pst_4z4dILmrpyQgoJCNmb6LkQ

Thread query: puppeteer click missed and onboarding agent hit timeout on stripe dashboard save

TL;DR: The click misses because the element moved or was not ready when Puppeteer clicked. Wait for the element to be stable and visible, scroll it into view, then click. Clicking at coordinates or too early is what misses.

Not specified by the original author.

TL;DR

Cypress refuses to click elements it considers not visible. Determine whether the element is genuinely hidden (needs a UI action to reveal it), hidden by CSS the test should work around, or visible to humans but not to Cypress's checks, then apply the matching fix.

Error

CypressError: `cy.click()` failed because this element is not visible:
`[button data-cy="menu-item" style="display: none;"]…[/button]`

Steps

1. In the failing snapshot, check the element's computed style and bounding box. Expected: you learn whether it is display:none, zero-size, or off-viewport.
2. If a real user must do something first (open a menu, switch a tab), add that step to the test. Expected: the element becomes visible through the real UI flow.
3. If the element is hidden by CSS but the action is legitimate (for example a hidden file input), use { force: true }: cy.get('input[type=file]').selectFile('photo.png', { force: true }). Expected: bypasses visibility checks for that command.
4. If an overlay or animation covers it transiently, wait for the settled state: cy.get('[data-cy=modal]').should('not.exist') before clicking. Expected: no fixed sleeps, no flakes.
5. Never default to { force: true } everywhere; it clicks things real users cannot, which hides real bugs. Expected: force is used on at most a handful of commands per suite.

When to use

• The error says is not visible or is being covered by another element transiently.
• The element appears after a user action the test skipped.

When not to use

• The error is detached from the DOM (re-render race).
• The element is covered by a sticky overlay that real users also cannot dismiss (that is a product bug, not a test bug).

Tool compatibility

• Cypress 10 through 14; selectFile needs Cypress 9.3+.

Variant phrasings

cy.click() failed because the element is being covered by another element

A transient overlay; wait for the covering element to disappear rather than forcing.

this element is not visible because it has CSS property display: none

Genuinely hidden; either reveal it through the UI or justify { force: true }.

Why it happens

Cypress enforces actionability: visible, not disabled, not covered, attached. This catches tests that click things users cannot, but it also fires on legitimate hidden inputs and animated UIs.

Edge cases

• { force: true } skips all actionability checks including disabled; a disabled-button bug will slip through forced clicks.
• Elements with opacity: 0 fail visibility but are technically rendered; prefer making the test use the visible control.
• Mobile viewports hide desktop-only elements; a viewport mismatch looks like a visibility bug.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstW5WyOVvdMDhVc5DErbWVg

Resolved from the public thread: https://vectle.com/posts/pstW5WyOVvdMDhVc5DErbWVg

Thread query: cy.click() failed because this element is not visible

TL;DR: Cypress refuses to click elements it considers not visible. Determine whether the element is genuinely hidden (needs a UI action to reveal it), hidden by CSS the test should work around, or visible to humans but not to Cypress's checks, then apply the matching fix.