Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cy.screenshot() not reflecting viewportWidth and viewportHeight settings, resulting in offset within the Cypress Test Runner #28586

Closed
Silencesnow opened this issue Dec 26, 2023 · 4 comments

Comments

@Silencesnow
Copy link

Current behavior

when using cy.screenshot() within the Cypress Test Runner , the settings for viewportWidth and viewportHeight are not being reflected, leading to offset related issues. I have chosen Chrome and Electron, and their sizes are different but both are different from the settings.
In #28541, I mentioned summary of the problem,and it was closed. I added some comments but didn't receive any further replies. Therefore, I decided to open a new issue to restate the problem. I hope to get it resolved.
the screenshot within the Cypress Test Runner and electron:
test -- Does not do much!
the screenshot within the Cypress Test Runner and chrome:
test -- Does not do much! (1)

Desired behavior

Within the Cypress Test Runner,the images generated by cy.screenshot() should match the dimensions set by viewportWidth and viewportHeight, and should have no offset.

Test code to reproduce

My config:

import { defineConfig } from 'cypress'
export default defineConfig({
  viewportWidth: 2000,
  viewportHeight: 1320,
  e2e: {},
})

my test:

describe('test', () => {
  it('Does not do much!', () => {
    expect(true).to.equal(true)
    cy.screenshot()
  })
})

Cypress Version

13.5.0

Node version

v16.15.1

Operating System

macOS 13.4

Debug Logs

No response

Other

No response

@jennifer-shehane
Copy link
Member

The previous issue was closed as a duplicate of #3324 with a workaround provided. I was able to reproduce it - it is the same issue tracked there. You can follow that issue for updates. We don't intend to work on this at this time. #3324

@jennifer-shehane jennifer-shehane closed this as not planned Won't fix, can't repro, duplicate, stale Dec 26, 2023
@Silencesnow
Copy link
Author

The previous issue was closed as a duplicate of #3324 with a workaround provided. I was able to reproduce it - it is the same issue tracked there. You can follow that issue for updates. We don't intend to work on this at this time. #3324

The issue I want to highlight is not the difference between open mode and run mode but rather that its behavior alone in open mode does not meet expectations.

@jennifer-shehane
Copy link
Member

Looking at this again.

@jennifer-shehane
Copy link
Member

Alright, I've figured out what's going on in this situation. And, it is in the same vein as the explanation in this comment #3324 (comment)

When running cypress open, the browser is opened in --headed mode, it will render an actual browser on the developer's screen. If you resize the browser to a width and height that is smaller than the viewport configuration, Cypress cannot take a screenshot that is larger than the browser's width and height. So if your browser is at 500 x 200, that is the max size of the screenshot and it is cropped.

I would recommend always running open mode in fullscreen. If you are using the screenshots for specific analysis, like screenshot diffing - I would recommend the workaround in #3324 (comment) and only take screenshots in an environment that will have a stable resolution and browser size by only taking them in headless mode.

There is an existing issue with Chrome rendering the chrome of the browser in Cypress 12.5.0+, where there is about 124px difference from the config variable, that is this issue that you can follow. #27260

I don't think there's anything we can do in this situation. We can't render the iframe/webpage larger than the actual browser in headed mode.

@jennifer-shehane jennifer-shehane closed this as not planned Won't fix, can't repro, duplicate, stale Dec 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants