Impact Score: 5/10
Cypress: 0.13.4
Source available — automated, not human-reviewed
Component: cypress · Channel: stable. Automated analysis, not a compatibility certification. How this works.
Analysis updated: 2026-11-01.
⚡ Executive Summary (TL;DR)
Cypress v0.13.4. Source highlight: *Released 12/31/2015*
Who Does This Impact? (Role-Based Analysis)
💻 Software Engineers & Devs
Check the source notes against the package and APIs you use before upgrading.
📊 Product & Engineering Leads
Use the documented changes to assess relevance to your product; release frequency alone is not a quality measure.
⚙️ DevOps & Security
Verify the target version, runtime requirements and rollback procedure in the official documentation.
✨ New Features & Capabilities (1)
- Added `waitForAnimations` and `animationDistanceThreshold` configuration options.
🔧 Bug Fixes & Patches (2)
- Cypress now automatically detects and waits for an element which is animating to stop animating. The threshold that Cypress considers *animating* is set to a distance of `5px` per `60fps`. In other words, if your element is moving too fast for a user to interact with, then Cypress considers the element animating and will wait until it finishes before attempting to interact with it. When we say 'interact' we mean apply command actions like .click(), .select(), .type(), .check(), etc. Waiting for
- Prevent `undefined` error when attempting to .click() an element which is fixed position when it is covered by another element. Cypress now correctly provides why it cannot click the element in question. Fixes #90.
📄 View Raw Release Notes (Original Developer Log)
*Released 12/31/2015*
**Features:**
- Added `waitForAnimations` and `animationDistanceThreshold` [configuration options](https://on.cypress.io/configuration#Animations).
- Cypress now automatically detects and waits for an element which is animating to stop animating. The threshold that Cypress considers *animating* is set to a distance of `5px` per `60fps`. In other words, if your element is moving too fast for a user to interact with, then Cypress considers the element animating and will wait until it finishes before attempting to interact with it. When we say 'interact' we mean apply command actions like [.click()](https://on.cypress.io/click), [.select()](https://on.cypress.io/select), [.type()](https://on.cypress.io/type), [.check()](https://on.cypress.io/check), etc. Waiting for animations prevents a series of edge cases and weird bugs where Cypress was interacting with elements **too** quickly which might cause undesired side effects in your application which are hard to track down. The downside to this implementation is that for every action Cypress must wait at least 2 run loops before applying actions. This slows down every action command by about `32ms`. If your app does not use animations you may wish to turn off this behavior in your `cypress.json` file.
**Bugfixes:**
- Prevent `undefined` error when attempting to [.click()](https://on.cypress.io/click) an element which is fixed position when it is covered by another element. Cypress now correctly provides why it cannot click the element in question. Fixes [#90](https://github.com/cypress-io/cypress/issues/90).
- Prevent infinite loop in edge cases when checking whether an element was hidden.
**Misc:**
- The default behavior of [cy.server()](https://on.cypress.io/server) has changed from `force404: true` to become `force404: false`. In other words, Cypress will no longer forcibly send XHR's to 404 status when these XHR's do not match any existing [cy.route()](https://on.cypress.io/route). This change better aligns with predictable usage for most Cypress users.