Current behavior

cy.screenshot relies on hasHelperPixels() to wait until the runner UI is hidden (app/fullPage) or present (runner capture). Today hasHelperPixels() samples the top-right and bottom-right helper pixels by calling image.getPixelColor(image.bitmap.width, …) and image.getPixelColor(…, image.bitmap.height). Those coordinates are width/height, but Jimp images are 0-indexed.

Impact

• For app/fullPage captures we expect the helper pixels to disappear before accepting the screenshot. Because the code samples the wrong coordinates, it may accept the shot before the runner UI finishes hiding.
• For runner captures we expect the helper pixels to be present. Since we never actually read the right-hand pixels, we can wrongly think the runner UI is ready, causing unnecessary retries or false positives.

Desired behavior

So the valid max coordinate is width - 1 / height - 1. Jimp silently returns the pixel at (0,0) whenever the requested coordinate is out of range, so our “right corner” checks always see the top-left pixels instead.

Test code to reproduce

• Take any spec that calls cy.screenshot({ capture: 'runner' }).
• Add logging in packages/server/lib/screenshots.ts inside hasHelperPixels().
• Observe that topRight/bottomRight always report the same color values as topLeft, even when you manually draw different colors in those corners.
• Or create a synthetic Jimp image with different colors in each corner and call hasHelperPixels(); the right-corner colors are never read.

Cypress Version

15.6.0

Debug Logs

Other

Root cause

hasHelperPixels() uses off-by-one coordinates when sampling helper pixels. Jimp returns (0,0) for out-of-range reads, so the logic never inspects the actual rightmost column/bottom row. The existing unit tests stub getPixelColor( width, … ) without exercising the real Jimp behavior, so they don’t catch this.