In Cypress, what does `{ force: true }` on `.click()` actually turn off?

## One switch, eight behaviours `{ force: true }` reads like "try harder", and it is the opposite: it is a switch that turns the readiness gate **off** rather than making it more permissive. Cypress documents exactly what it stops doing when an action command is forced. | Skipped when forced | Consequence | |---|---| | Scroll the element into view | The page is left where it is; the element may be off screen | | Ensure it is visible | A `display: none` element receives the events | | Ensure it is not disabled | A `disabled` Borrow button receives a click a user could never give it | | Ensure it is not detached | An element the app already removed can still be targeted | | Ensure it is not readonly | `.type()` will type into a locked search box | | Ensure it is not animating | The event lands mid-transition, wherever the element happens to be | | Ensure it is not covered | The modal over the button is irrelevant to Cypress | | Fire the event at a descendant | The event goes to the element you targeted, not to whatever sits at those coordinates | That last row is the one people forget. Unforced, Cypress resolves the deepest element at the event coordinates and fires there — which is why a click on a button with an inner `<span>` is reported against the span. Forced, that resolution is skipped and the target is exactly the element the chain yielded. ## What force does not change - **Everything after the gate still happens.** Cypress fires the same event sequence and the browser performs the same default actions; a forced click is a real click, just an unvetted one. - **The element still has to exist.** `cy.get('[data-cy=borrow]')` must yield something before the action runs at all, and the query's own retries are untouched by `force`. - **`.select()` keeps one refusal.** Forcing `.select()` will not let you choose a `disabled` `<option>` or an option inside a disabled `<optgroup>`. - **Assertions are unaffected.** A forced click does not make a later `.should()` pass; it only changes what had to be true before the event. ## The narrower switches Reaching for `force` because one check is failing throws away the other seven. Cypress exposes narrower options for the two checks that are most often genuinely in the way: 1. `{ waitForAnimations: false }` — drops the animation check alone and leaves visibility, disabled, readonly and coverage in place. 2. `{ animationDistanceThreshold: 20 }` — keeps the animation check but tolerates faster movement. 3. `{ scrollBehavior: false }` — skips the scroll step alone, for a page whose scroll position the test has deliberately set. Those three cover most of the honest cases. What is left for `force` is the situation where the interaction genuinely cannot be reproduced as a user would perform it — a hover-only menu, a control a third-party widget covers on purpose — and the value of the test is in what happens after the event, not in the reachability of the control. ## Why forced actions age badly A forced action **cannot fail for the reason you would want it to**. If a redesign leaves the Borrow button under a permanent overlay, or ships it permanently `disabled` for logged-out readers, the forced click still fires, the app's handler still runs, and the test still passes — while every real reader is blocked. The check you removed was the only part of the test that could have noticed. The practical shape of this in a suite: - A forced action deletes coverage of the element's reachability; keep the check somewhere else, such as an explicit `.should('be.visible')` or `.should('not.be.disabled')` before the forced step, so the intent is still asserted. - `force` on a `.type()` is a stronger smell than `force` on a `.click()`, because it means the field was `disabled` or `readonly` and the app was telling you not to type. - A `force` that was added to fix flake is usually a timing problem wearing a disguise: the check it silences was reporting a state the app really was in, briefly. In short: `{ force: true }` is not a stronger click, it is an unchecked one, and it is worth knowing all eight of the things it stops doing before adding it to a chain.