fix: correct helper pixel detection

[weillercarvalho]

• Closes cy.screenshot helper pixel check uses out-of-bounds coordinates #32927

Additional details

• Fixes hasHelperPixels() so it samples the real right/bottom helper pixels (the previous off-by-one coordinates caused Jimp to
  fall back to (0,0), allowing cy.screenshot to accept captures before the runner UI was fully hidden or visible).
• Updates packages/server/test/unit/screenshots_spec.js to expect the corrected coordinates and adds a regression test that fails
  if getPixelColor reads outside [0, width-1] × [0, height-1], preventing the bug from regressing.

Steps to test

1. From the repo root run yarn workspace @packages/server test test/unit/screenshots_spec.js.
2. Observe that the helper-pixel tests pass. (On WSL/OneDrive the suite stops early with “no browsers found in machineBrowsers”;
   on macOS/Linux with Chrome/Edge installed the spec completes.)

How has the user experience changed?

Before: cy.screenshot({ capture: 'app' | 'fullPage' }) could finish while the runner UI was still visible because the helper-
pixel detector always read (0,0).
After: the detector clamps the coordinates, so screenshots aren’t accepted until the helper pixels truly disappear/appear.

PR Tasks

• Have tests been added/updated?
• [na] Has a PR for user-facing changes been opened in [cypress-documentation](https://github.com/cypress-io/cypress-
  documentation)?
• [na] Have API changes been updated in the [type definitions](https://github.com/cypress-io/cypress/blob/develop/cli/types/
  cypress.d.ts)?

---

Note

Clamp helper pixel sampling to image bounds in screenshot detection, update unit tests accordingly, and note the bugfix in the changelog.

• Server (screenshots):
  • Update hasHelperPixels() in packages/server/lib/screenshots.ts to clamp sampled coordinates within [0..width-1] × [0..height-1], preventing out-of-bounds reads.
• Tests:
  • Revise packages/server/test/unit/screenshots_spec.js to stub getPixelColor on the image instance, use last-index coords, and add a regression test asserting no OOB pixel reads.
  • Stabilize test setup by stubbing browserApi.getBrowsers and adjusting timeouts.
• Changelog:
  • Add bugfix entry documenting the screenshot helper pixel bounds issue.

^{Written by Cursor Bugbot for commit f2912bd. This will update automatically on new commits. Configure here.}

[CLAassistant]

All committers have signed the CLA.

[cypress-app-bot]

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.

[jennifer-shehane]

@weillercarvalho Very interesting find. I will run the tests to see if they pass.

[jennifer-shehane]

@weillercarvalho There is a failure here you can see in CircleCI:

  1) lib/screenshots .capture does not read helper pixels outside the bitmap bounds:
     TypeError: this.getPixelColor.restore is not a function
      at Context.<anonymous> (test/unit/screenshots_spec.js:165:26)
      at processImmediate (node:internal/timers:485:21)

[jennifer-shehane]

@weillercarvalho It might be helpful to know that our jimp version currently in this repo is 0.22.12.

[weillercarvalho]

@jennifer-shehane Thank you for the clarification. I will look into the error, try to correct it, and commit later.

[weillercarvalho]

@jennifer-shehane I fixed the failing spec by making fake Jimp image behave the way the real library does: it now defines a getPixelColor method and we stub that method with Sinon, so the new “helper pixels stay in-bounds” test can call .restore() without error. I also stubbed ctx._apis.browserApi.getBrowsers in the suite’s before/after hooks to return a deterministic Chromium entry; that keeps the DataContext from throwing “no browsers found” when the test environment can’t detect real browsers, ensuring the updated helper-pixel logic and its regression test both run cleanly.

Also all unit tests passed as well, so now I hope that everything its okay.