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

Chrome: Support true headless mode #25972

Closed
Lokideos opened this issue Feb 28, 2023 · 8 comments · Fixed by #26481
Closed

Chrome: Support true headless mode #25972

Lokideos opened this issue Feb 28, 2023 · 8 comments · Fixed by #26481
Labels
browser: chrome E2E Issue related to end-to-end testing existing workaround Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team. type: feature New feature that does not currently exist

Comments

@Lokideos
Copy link

What would you like?

Context

In a recent update, Chrome updated the headless mode.

According to the article, Google had two separate builds for Chrome: one for headless, and one for headful modes, which might have potentially created problems for automation engineers since there might've been differences between Chrome behavior in the test environment and in the production environment.

After the recent update, it is no longer the case.

Implementation

Mathias and Peter describe in the article how to opt to the new headless mode for Puppeteer and Selenium-WebDriver, but, unfortunately, don't do it for Cypress.
Though, I think that implementation examples can give a general idea of how to do it in Cypress.

Why is this needed?

To avoid potential inconsistencies between the test environment, in which we run Cypres tests, and the production environment.

Other

No response

@nagash77
Copy link
Contributor

Hi @Lokideos , thanks for submitting this feature request. This is something we have been discussing internally as well. There are no firm timelines on when this will be done, but we are definitely aware and hope to prioritize it in the future. I am going to close this issue as we have internal resources dedicated to this initiative.

@nagash77 nagash77 added the type: feature New feature that does not currently exist label Feb 28, 2023
@nagash77 nagash77 reopened this Feb 28, 2023
@nagash77
Copy link
Contributor

nagash77 commented Feb 28, 2023

Reopening! Going to use this as the public facing ticket for this work and add it to our Cypress App Priorities Board. Thanks again @Lokideos for submitting this!

@emilyrohrbough emilyrohrbough changed the title Support true headless mode Chrome: Support true headless mode Feb 28, 2023
@jennifer-shehane
Copy link
Member

Another user posted this workaround. I haven't tried it specifically, but it looks like it should be a workaround to make passing the new headless flag work today until we get this built into the product as the default.

we can use these new options ** right now ** by overriding the behavior of Cypress' --headless in before:browser:launch like this in cypress.config.js. Don't forget this is nested in the e2e section most likely.

setupNodeEvents: function setupNodeEvents(on, config) {
  on('before:browser:launch', (browser = {}, launchOptions) => {
    if (browser.name === 'chrome' && browser.isHeadless) {
      const version = parseInt(browser.majorVersion);
      if(version >= 109) {
        launchOptions.args.push('--headless=new');
      } else if(version >= 96 && version < 109) {
        launchOptions.args.push('--headless=chrome');
      } else {
        launchOptions.args.push('--headless')
      }
    }
    return launchOptions;
  });
}

@chrishalebarnes
Copy link

Author of the above workaround here. Been having some problems running with this new option in an oddly specific circumstance.

If the last page visited has a YouTube embed, it fails to close the remote debugging socket and hangs forever, but cannot reproduce this locally, only in CI. And it happens like 80% of the time, so it seems to be a timing issue? Without --headless=new it passes 100% of the time.

It gets here but never gets here.

It seems as if it tries to close Chrome via CRI, and then the YouTube embed (in an iframe) makes some requests after that attempt, which interferes in some way. Is this reconnect logic, stuck in a loop perhaps?

Also open to providing debug logs if that helps, let me know.

If anyone else experiences something like this running with --headless=new, please chime in!

@jennifer-shehane
Copy link
Member

@chrishalebarnes Thanks for bringing this up. We intend to update Cypress to pass headless=new by default, so there's still some investigation needed on our side to make sure there isn't any unexpected behavior when we turn it on. We'll try to take a look at the issue you surfaced.

@jpaquit
Copy link

jpaquit commented Apr 19, 2023

Adding --headless=new allows me to make headless chrome download feature behaves as headed chrome would: downloaded filename has expected filename and not a random UUID filename.

@nagash77 nagash77 added E2E Issue related to end-to-end testing Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team. and removed routed-to-e2e labels Apr 19, 2023
@jennifer-shehane
Copy link
Member

@jpaquit interesting, can you elaborate on what the behavior was doing before the headless new flag? I'm unaware of this being a benefit of passing headless=new, but would love to understand more.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jun 20, 2023

Released in 12.15.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v12.15.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Jun 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
browser: chrome E2E Issue related to end-to-end testing existing workaround Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team. type: feature New feature that does not currently exist
Projects
Status: Generally Available
Development

Successfully merging a pull request may close this issue.

6 participants