Cypress: Redirected to chrome-error://chromewebdata/ when X-Frame-Options present on redirected domain

[gerardovanegas-eagle]

Current behavior:

I get this screen when I try to access certain pages:

This I can easily access on the same browser used by cypress

I have my "chromeWebSecurity": false on my cypress file just in case

Desired behavior:

Continue executing the test. Access the pages that are completely accessible when not accessed through cypress' chrome

Steps to reproduce: (app code and test code)

This is my code, I hope this one is reproducible:

describe('Happy Path B2C / Checkout V2 ', function () {
beforeEach("Home - Catalog - PP - Cart", function(){

        //Going directly to product's page 
        cy.visit('https://juntozstagingv2.com/es-pe/');

        //Closing Ads
        cy.get("div[data-action='close-mc-modal']").click({force:true})

        //Triggerin Login
        cy.get("a[aria-haspopup='true']").click();
        cy.get("a[href='https://juntozstagingv2.com/account/login']").click();
    })
});

┆Issue is synchronized with this Jira Epic by Unito

[jennifer-shehane]

Cypress cannot visit 2 superdomains within the same test. Although the href does equal juntozstagingv2, the url is redirecting to account.juntoz-staging.com upon click.

I would suggest taking a look at one of our recipes testing clicking into links with a different domain and restructuring your test to account for this.

[emijmker]

I have the same issue, it works in 3.2.0. After updating to 3.3.1 i now get this error as well.
Also have "chromeWebSecurity": false, yes working cross domain but didn't have the issue before the update.

[Vinod-Gulia]

I'm facing the same issue after upgrading cypress to [email protected]. Is there a solution found already?

[dave0688]

Have exactly the same issue. Cypress looks nice, but if such "simple" things do not work it's hard to work with it.

[Sjeiti]

I would suggest taking a look at one of our recipes testing clicking into links with a different domain and restructuring your test to account for this.

We get the same error and we're on one superdomain. We are however using a subdomain for authentication.
The referenced solutions are specifically for other superdomains.

The last version that still worked for us was 3.2.0

When we install the latest Cypress (3.4.1) the tests run up until the first redirect (from https://bar.foo to https://login.bar.foo). It errors with the cross-origin error message.

When we add chromeWebSecurity:false to the settings we fail before redirecting to a subdomain with chrome-error://chromewebdata/ in the address bar and the following error stacktrace (failed trying to load):

Error: write EPROTO 101057795:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:c:\projects\electron\vendor\node\deps\openssl\openssl\ssl\s23_clnt.c:802:

    at _errnoException (util.js:1024:11)
    at WriteWrap.afterWrite (net.js:867:14)

Cypress 3.3.0 throws the same errors so something in that changelog should have caused it.

The one change that stands out are the proxy settings. We did find a proxy in the registry but adding it to HTTP_PROXY and HTTPS_PROXY simply causes the tests to fail altogether (a blank test page without the Cypress ui). Previously it failed after login.
We did suddenly get the message that Cypress couldn't verify the baseurl running (which is running).

Maybe it is not really a proxy issue ? (since we can login but the subdomain redirect fails)
We are running out of ideas here.

[pardonmeme]

Also got that issue, Our app is redirecting directly to our auth(which is a seperated domain) if user is not logged in and then redirects back to the app. But it seems like it just shows that chrome-error://chromewebdata/

:/

[chhiragkataria]

We are facing the same issue - on 3.4.1 and see chrome-error://chromewebdata/
Has anyone found a workaround?
Why is the cypress team not looking into it?

[gastonmorixe]

Same

[soomro12]

Same issue we are facing. Any solution??

[PrinceSoni83]

I also have the same issue with chrome Version 78.0.3904.108

[as001622]

It seems related to chromium version, after installing chrome Version 78.0.3904.108-1 I was available to run tests without that error.

[adomyaty55foundry]

Reporting in, I'm having this same issue and would love for Cypress to better handle/solve this. It's an annoying one especially when testing OAuth2 and other stuff that requires domain changing. These things are common nowadays and we should account for allowing us to test such cases.

[JasonTheAdams]

~Same issue here while using the same superdomain. The tests work locally, but when running on CircleCI we're running from http://localhost:8000. The page redirects to http://app.localhost:8000 after login is successful. This is when the error happens.~

Turns out that our issue had to do with the domains not resolving properly in the container. I did some dnsmasq work and that resolved the issue. In short, we're using actual domains (not localhost) in our CircleCI tests now and set up a dnsmasq wildcard to catch everything for the domain.

[gmbarroso]

@jennifer-shehane is there any updates where it will be possible to access more domains at the same test? Cause it seems a lot of people try this.

Me, for example, I can't open some modal in a table just because this modal verifies the user token to open it.

I'm keeping having this issue and it is really annoying.

Thanks

[webartdev]

Same issue here while testing Auth and other stuff that requires domain changing.

[JasonTheAdams]

I want to loop back and report that our issue was our own problem. I've updated my comment above.

[HumbertoF]

same issue here, it is very annoying! :(

[visuallization]

We are having the same issue on cypress 3.5.0 and "chromeWebSecurity": false set.

[jennifer-shehane]

Unfortunately no one has provided enough information to reproduce the problem. This means that we do not have a path to move forward, so no, no progress has been made on this issue as we cannot see this error on our machines with no reproducible example.

Please comment in this issue with a reproducible example so we can begin addressing the issue.

[khitrenovich]

Can this be a duplicate of https://github.com/cypress-io/cypress/issues/1506 maybe?

[AlexanderHritsun]

Good day everyone! I have the same issue and wanna describe how I fixed it.

Application features:
1) We have the main domain - https://condogenie-app and can create "accounts" from it. Every account has own subdomain for example: https://staging.condogenie-app where "staging" is the unique account name
2) To create a new account we are navigating to https://condogenie-app/account-sign-up.
On this page, we set the account name and click the 'Finish' button. After this action system navigates us to subdomain page: https://staging.condogenie-app/account-sign-up-finish
Exactly on this step, the issue arises.

Strangeness:
1) The issue started to reproduce one week ago before it no problems occurred
2) If "chromeWebSecurity": true - cypress shows 'cross-origin security' error
3) If "chromeWebSecurity": false- we get chrome-error://chromewebdata/ and the cypress runner crashed

How I fixed it:
It was surprising for me, but no error arises for my old code(which was written several weeks or months ago). So I started comparing new and old code and couldn`t find any differences. That why I decided to copy the old code to the new file(it is working). After that I started to delete parts of the old code and found that the issue arises if we change the variables names!
Example of variables with which tests passed:

export const renterEmail = '[email protected]';
export const renterFname = 'Renter';
export const renterLname = 'Book';
export const accountName = `bookings${Date.now()}`; 

Example of variables with which tests failed:
js export const accountName = `bookings_tests${Date.now()}`; export const renterEmail = '[email protected]'; export const renterFname = 'Renter'; export const renterLname = 'Bookings';

I can`t explain this strange behavior. I tried to change variables import order but it changes nothing. Besides, if I write a new code it will be crashed.
Hope this information will help you in the issue investigation

[visuallization]

Good day everyone! I have the same issue and wanna describe how I fixed it.

Application features:

1. We have the main domain - https://condogenie-app and can create "accounts" from it. Every account has own subdomain for example: https://staging.condogenie-app where "staging" is the unique account name
2. To create a new account we are navigating to https://condogenie-app/account-sign-up.
   On this page, we set the account name and click the 'Finish' button. After this action system navigates us to subdomain page: https://staging.condogenie-app/account-sign-up-finish
   Exactly on this step, the issue arises.

Strangeness:

1. The issue started to reproduce one week ago before it no problems occurred
2. If "chromeWebSecurity": true - cypress shows 'cross-origin security' error
3. If "chromeWebSecurity": false- we get chrome-error://chromewebdata/ and the cypress runner crashed

How I fixed it:
It was surprising for me, but no error arises for my old code(which was written several weeks or months ago). So I started comparing new and old code and couldn`t find any differences. That why I decided to copy the old code to the new file(it is working). After that I started to delete parts of the old code and found that the issue arises if we change the variables names!
Example of variables with which tests passed:

export const renterEmail = '[email protected]';
export const renterFname = 'Renter';
export const renterLname = 'Book';
export const accountName = `bookings${Date.now()}`; 

Example of variables with which tests failed:

export const accountName = `bookings_tests${Date.now()}`;
export const renterEmail = '[email protected]';
export const renterFname = 'Renter';
export const renterLname = 'Bookings';

I can`t explain this strange behavior. I tried to change variables import order but it changes nothing. Besides, if I write a new code it will be crashed.
Hope this information will help you in the issue investigation

Thank you for taking the time to report this here! That's a strange issue indeed. Let's hope cypress team has some ideas.

[anveshpuli]

Facing the same issue , tried setting the cookies SameSite = none but haven't got any better results . Looking forward to hear back soon!!

[XiangyangShi]

Reporting in, similar with adomyaty55foundry@

My website is for internal use and I use Cypress for testing OAuth2.
[tab_handling_anchor_links_spec.js] doesn't help since the login button will contains lots redirects and the middle station is within another Authorizer domain we own. These things are common use cases nowadays.

[jennifer-shehane]

Unfortunately no one has provided enough information to reproduce the problem. This means that we do not have a path to move forward, so no, no progress has been made on this issue as we cannot see this error on our machines with no reproducible example.

Please comment in this issue with a reproducible example so we can begin addressing the issue.

[pshynin]

to reproduce the problem you really need to click the link with external resource like itunes, google play store, amazon etc..
test will look like this example provided by cypress team: https://github.com/cypress-io/cypress-example-recipes/blob/master/examples/testing-dom__tab-handling-links/cypress/integration/tab_handling_anchor_links_spec.js#L74

Since Cypress does not support switching between tabs, we need to make it open in current tab resetting href attribute to default _target value by removing it entirely:

.invoke('removeAttr', 'target')

or by setting it to _self :

.invoke('attr', 'target', '_self')

then source will be opened in current tab and another problem will appear as described in this ticket:

(NEW URL)
chrome-error://chromewebdata/
URL
ASSERT
expected chrome-error://chromewebdata/ to include google.com

as you can see I expected cy.url().should('include', 'google.com'); but instead url was chrome-error://chromewebdata/

Example of button to click:

<a href="https://play.google.com/store/apps/details" test-id="google-play" target="_blank">

Example of test verification:

cy.get('[test-id="google-play"]').invoke('attr', 'target', '_self').click();
cy.url().should('include', 'google.com');

PS: I also tried exporting HTTP_PROXY but this did not work either and is really overkill especially in case where we have many links to test.

hopefully this is something cypress team willing to implement sooner

[jennifer-shehane]

@pshynin Thank you for providing a reproducible example!

The below example does not error if the link is going to say, example.cypress.io, so the issue doesn't lie in itself with clicking a _self link, but something combined with the play.google.com website being the link target.

To reproduce

cypress.json

{
  "chromeWebSecurity": false
}

index.html

<html>
<body>
  <a href="https://play.google.com" target="_self">Google</a>
</body>
</html>

spec.js

it('Visit cross origin link', () => {
  cy.visit('index.html')
  cy.get('a').click()
  cy.url().should('include', 'google.com')
})

This used to show the 'Whoops, we can't run your tests' error and open the new link in a new tab prior to 3.2.0. But, it's never really worked correctly.

3.1.5

3.2.0

[pshynin]

is 'Whoops, we can't run your tests' expected result ?
though expected is to actually handle external link in current tab

unless we can switch between tabs back and forth.. (which isn't supported I think)

[ysdidenko]

We have the same issue. We use a call to an external link for authorization.
cy.request('https://our-identity-server.com');
It worked well until 3.2.0.
Most interesting thing is that it works on Electron 78, but fails with Chrome 80

[jennifer-shehane]

@pshynin No, neither of these results are considered working.

Ok, even better - I was able to replicate this with an application under our control. This happens when the link clicked is https://www.cypress.io with no target attr needed.

This is super strange.

cypress.json

{
  "chromeWebSecurity": false
}

index.html

<html>
<body>
  <a href="https://example.cypress.io">Example</a>
  <a href="https://docs.cypress.io">Docs</a>
  <a href="https://www.cypress.io">Cypress</a>
</body>
</html>

spec.js

it('Visit cross origin link 1', () => {
  cy.visit('index.html')
  cy.contains('Example').click()
  cy.url().should('include', 'example.cypress.io') // passes
})

it('Visit cross origin link 2', () => {
  cy.visit('index.html')
  cy.contains('Docs').click()
  cy.url().should('include', 'docs.cypress.io') // passes
})

it('Visit cross origin link 3', () => {
  cy.visit('index.html')
  cy.contains('Cypress').click()
  // expected chrome-error://chromewebdata/ to include www.cypress.io
  cy.url().should('include', 'www.cypress.io') // fails
})

[Bheemaanil]

same issue on "cypress": "^4.0.1" with "chromeWebSecurity": false, :(

[ysdidenko]

Upgrading to 4.2.0 fixed an issue for us

[khitrenovich]

Upgrading to 4.2.0 fixed an issue for us

Nothing changed after upgrade to v4.2 for us. We see the same error in our project.

[PiteroS678]

Hi,
You can overcome that by proxy which will tell browser to allow specific ancestors of iframe through sending additional Content-Security-Policy header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) with response of page which has different domain.

For example (using mitmproxy https://github.com/mitmproxy/mitmproxy on Windows):

1. Create an addon which will add the header to response (example below adds the header to all responses processed by proxy).

from mitmproxy import http

def response(flow: http.HTTPFlow) -> None:
    flow.response.headers["Content-Security-Policy"] = "frame-ancestors https://juntozstagingv2.com"

1. Load the addon with mitmproxy startup i.e: mitmweb -s path/to/addon.py
2. Tell Cypress to use mitmproxy through System variable (other OS: https://docs.cypress.io/guides/references/proxy-configuration.html#Set-a-proxy-on-Linux-or-macOS)
   Name: HTTP_PROXY
   Value: 127.0.0.1:8080 - default proxy address
3. Open new console and launch cypress ("chromeWebSecurity": false in cypress.json is still required)

From now, the error shouldn't appear :)

[sharif331]

@jennifer-shehane Hi, I am looking for new automation tools for my current organization and I am exploring cypress with one of our projects and I am also getting same issues, is Cypress team is working on this issue to resolve it. If you can give any update on this issue that will be a great help for my project is having lots of subdomains so this is very much important for me.

[poponuts]

Upvote here. I am having same error.

[AndersonZacharyT]

same same

[headfox23]

Same issue...even with the Ignore-X-Frame-headers_v1.1 loaded headless it does not work

[khitrenovich]

@jennifer-shehane I have some input other that "same same" here.

We have an app with the following setup -

+---------+                 +-------+ +-----+
| Browser |                 | MyApp | | IdP |
+---------+                 +-------+ +-----+
     |                          |        |
     | Click "Login" button     |        |
     |------------------------->|        |
     |                          |        |
     |          Redirect to IdP |        |
     |<-------------------------|        |
     |                          |        |
     | Start login flow         |        |
     |---------------------------------->|
     |                          |        |
     |           Show credentials prompt |
     |<----------------------------------|
     |                          |        | ------------------------\
     |                          |        |-| multi-step login flow |
     |                          |        | |-----------------------|
     |                          |        |
     |            Redirect back to MyApp |
     |<----------------------------------|
     |                          |        |

Cypress is able to make through the login flow when MyApp is deployed in the cloud (in S3, behind CloudFront, with real URL/certificate and such), but fails with chrome-error:// on redirect to IdP when testing it locally (deployed on http://localhost:8080.

Obviously, in both cases IdP is a cloud service with valid FQDN and certificate.

Hope it helps.

[paprikati]

Hi @jennifer-shehane
We're on cypress 4.2.0.
We have a redirect component, which calls window.location.assign(externalURL).
The externalURL is calling another port on localhost - there's no server there though.

Ideally, I'd be able to assert that the url has changed (cy.url() etc), and then move on (I don't need to actually load the page - I just want to assert that the redirect has occurred).

I think this is the same issue? I again receive the error

[vijayfelixraj]

I have same issue. Please help.

Thanks in advance

[jennifer-shehane]

So, when I try to recreate this visiting our www.cypress.io website while locally running it...I can't reproduce it.

Localhost

spec.js

it('Visit cross origin link 3', () => {
  cy.visit('index.html')
  cy.contains('Cypress').click()
  cy.url().should('include', 'localhost') // passes 🙄 
})

index.html with website locally running

<html>
<body>
    <a href="http://localhost:8000/">Cypress</a>
</body>
</html>

URL doesn't exist

I can recreate this with a url that doesn't exist:

index.html

<html>
<body>
    <a href="https://foobar">Foobar</a>
</body>
</html>

spec.js

it('Visit cross origin link 3', () => {
  cy.visit('index.html')
  cy.contains('Foobar').click()
  // redirects to chrome-error://chromewebdata/
  cy.url().should('include', 'foobar') // fails
})

  cypress:server:server HTTPS request does not match URL: https://foobar:443 with props: null +1ms
  cypress:https-proxy Making connection to foobar:443 +0ms
  cypress:https-proxy getting proxy URL { port: 443, serverPort: 54700, sniPort: 54702, url: 'https://foobar:443' } +0ms
  cypress:network:connect received error on connect, retrying { iteration: 0, delay: 0, err: Error: getaddrinfo ENOTFOUND foobar     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26) { errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'foobar' } } +134ms
  cypress:network:connect received error on connect, retrying { iteration: 1, delay: 100, err: Error: getaddrinfo ENOTFOUND foobar     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26) { errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'foobar' } } +4ms
  cypress:server:run browser launched +935ms
  cypress:network:connect received error on connect, retrying { iteration: 2, delay: 200, err: Error: getaddrinfo ENOTFOUND foobar     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26) { errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'foobar' } } +105ms
  cypress:network:connect received error on connect, retrying { iteration: 3, delay: 200, err: Error: getaddrinfo ENOTFOUND foobar     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26) { errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'foobar' } } +206ms
  cypress:network:connect retries exhausted, bubbling up error { iteration: 4, err: Error: getaddrinfo ENOTFOUND foobar     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26) { errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'foobar' } } +208ms
  cypress:https-proxy received upstreamSocket callback for request { port: '443', hostname: 'foobar', err: Error: getaddrinfo ENOTFOUND foobar     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26) { errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'foobar' } } +527ms
  cypress:https-proxy received error on client browserSocket { err: Error: getaddrinfo ENOTFOUND foobar     at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:60:26) { errno: 'ENOTFOUND', code: 'ENOTFOUND', syscall: 'getaddrinfo', hostname: 'foobar' }, url: 'foobar:443' } +0ms

www.cypress.io

I can recreate this however visiting our staging or production website, meaning something is changed during deployment that is affecting this.

spec.js

it('Visit cross origin link 3', () => {
  cy.visit('index.html')
  cy.contains('Cypress').click()
// redirects to chrome-error://chromewebdata/
  cy.url().should('include', 'cypress.io') // fails
})

index.html

<html>
<body>
    <a href="https://www.cypress.io/">Cypress</a>
</body>
</html>

  cypress:server:server Got CONNECT request from www.cypress.io:443 +79ms
  cypress:https-proxy Writing browserSocket connection headers { url: 'www.cypress.io:443', headLength: 0, headers: { host: 'www.cypress.io:443', 'proxy-connection': 'keep-alive', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Cypress/4.4.0 Chrome/80.0.3987.158 Electron/8.2.0 Safari/537.36' } } +919ms
  cypress:https-proxy Got first head bytes { url: 'www.cypress.io:443', head: '\u0016\u0003\u0001\u0002\u0000\u0001\u0000\u0001�\u0003\u0003�K\u0019�&��N��E�ref�/󺄒���/67�,}� \\�!$��&\u0018��1J\u000e\u001e���h\f���' } +1ms
  cypress:server:server HTTPS request does not match URL: https://www.cypress.io:443 with props: null +1ms
  cypress:https-proxy Making connection to www.cypress.io:443 +0ms
  cypress:https-proxy getting proxy URL { port: 443, serverPort: 54719, sniPort: 54721, url: 'https://www.cypress.io:443' } +0ms
  cypress:network:connect successfully connected { opts: { port: '443', host: 'www.cypress.io', getDelayMsForRetry: [Function: getDelayForRetry] }, iteration: 0 } +207ms
  cypress:https-proxy received upstreamSocket callback for request { port: '443', hostname: 'www.cypress.io', err: undefined } +80ms
  cypress:server:util:socket_whitelist whitelisting socket { localPort: 54733 } +1s
  cypress:server:run browser launched +929ms
  cypress:server:socket automation:request take:screenshot { titles: [ 'Visit cross origin link 3' ], testId: 'r2', simple: true, testFailure: true, capture: 'runner', clip: { x: 0, y: 0, width: 1000, height: 660 }, viewport: { width: 1280, height: 720 }, scaled: true, blackout: [], startTime: '2020-04-14T09:06:11.117Z' } +5s

[MariyaQA]

Cypress version 4.4.0
same issue

trying to test payment methods in sandbox. It's weird that testing of PaySafe method is working correct(transfer from one superdomain to another, fill info and go back), but iDeal method is failed with chrome-error://chromewebdata/ when redirect should perform

[paprikati]

@jennifer-shehane - could it be about CORS? if chrome is hitting the OPTIONS command first, and then gets something it doesn't like and falls over?
They made some CORS changes in v76 https://bugs.chromium.org/p/chromium/issues/detail?id=989443

[MisterGlass]

Started seeing this issue in CI yesterday. We pushed a big folder restructure to our repo and it broke builds for a few days, when we were fixing it all we ran into this.

We do not see this running the client CLI or interactive. But we use the cypress/included:4.4.0 docker image to run the tests in CI. I ran my tests from that and was able to reproduce the error locally.

So, it works when invoked in my local (OSX Catalina) shell, but doesn't in the docker image.

[chepelevdi]

Same Issue, any updates on this?

[niallobrien]

Running into this same issue atm.

[poponuts]

Started seeing this issue in CI yesterday. We pushed a big folder restructure to our repo and it broke builds for a few days, when we were fixing it all we ran into this.

We do not see this running the client CLI or interactive. But we use the cypress/included:4.4.0 docker image to run the tests in CI. I ran my tests from that and was able to reproduce the error locally.

So, it works when invoked in my local (OSX Catalina) shell, but doesn't in the docker image.

See if rolling back to the previous version of Cypress works (4.3.0). I used that as a workaround as I had heaps of issues with the latest version.

[jennifer-shehane]

@paprikati Testing this theory - running the test above through Chromium 75 should work. I've run it through Chromium 75 and it is the same failure - rerouting to
chrome-error://chromewebdata/, so I don't think this is the issue.

[MisterGlass]

@poponuts Sorry, I forgot to mention, we were on an old version (I think 3.7?) before we ran into this. As one of my early debug steps I upgraded to the highest revision in three and then after a cursory look at the changelog moved to latest.

Big thanks to cypress for making upgrades super easy, no trouble with the major version upgrade.

So I don't think a rollback to 4.3 would help, considering we tried multiple older versions. If I have spare time in the morning I might fire off a run anyway.

[MisterGlass]

@jennifer-shehane Are there any updates on this? At the moment we are removing the tests from our CI pipeline because they always erroneously fail.

[chepelevdi]

I resolved this issue with help of this guide
https://medium.com/@you54f/configuring-cypress-to-work-with-iframes-cross-origin-sites-afff5efcf61f

plus switched default electron browser to chrome.
(I'm using latest cypress version)

[matusferko]

This error is showstopper. We should not hack cypress config to fix it

[anveshpuli]

Facing the same issue with later cypress version 4.4.1 and chrome: 81 , even adding the Ignore X frame Headers isn't working now @chepelevdi

[niallobrien]

No updates and this is a blocker for us atm.

[sebastianplesciuc]

Just a thought, but some websites, especially when federating logins, cause this error in the console:

Refused to display 'https://....' in a frame because it set 'X-Frame-Options' to 'deny'.

Which causes the same behavior of chrome-error://chromewebdata/ even though this config is set: "chromeWebSecurity": false

Some workarounds have been proposed here: https://github.com/cypress-io/cypress/issues/1763

[LieAlbertTriAdrian]

Are there any updates regarding this issue?

1. In headed mode and chrome browser, it will work perfectly after you install a chrome extension https://github.com/cypress-io/cypress/issues/1763#issuecomment-394492373
2. However, in headless mode and chrome browser, the error will still persist.

Does anyone know how to perform case 2?

[aleblanc]

Same issue and with the Ignore-X-Frame-headers_v1.1.1 extension it's also does not work

[MisterGlass]

Hi, any updates or timeline on this? This bug is really a showstopper for us.

[afrancht]

@jennifer-shehane

This is an absolute showstopper for us and in all honesty, the fact that so many people are commenting that this is an issue and it is not addressed because nobody can give steps to be reproduced is no justification for not addressing it after a year. The test failing is so simple that it shouldn't need to try to be reproduced. But here it goes:

• cypress 4.4.1
• node 8.8.1
• Running Chrome 83

This is my test:

describe('Login Page', () => {
    beforeEach(() => {
        cy.server();
        cy.visit('/');
    });

    it.only('Has a Sign Up / Log In Section with logo and button', function() {
        cy.get('[data-cy="authenticationSection"]');
        cy.get('[data-cy="signupSection-logoBlue"]');
        cy.get('[data-cy="signupSection-button"]').click();
        // cy.location('pathname').should('include', 'auth0');
    });
});

I have a very simple react component:

import React from 'react';
import { connect } from 'react-redux';

// Styling
import { Flex, Image } from 'rebass';
import { withStyles } from '@material-ui/core/styles';
import { Card, Button } from '@material-ui/core';

// Local Imports
import logoBlue from '../assets/images/logo_blue.png';

import { useAuth0 } from '../react-auth0-spa';

// Local Style
const styles = theme => ({
    root: {
        flex: 1,
        display: 'flex',
        padding: theme.spacing(6, 4),
        background: '#eaeff1',
        width: '100%',
        alignItems: 'center',
        justifyContent: 'center',
    },
    card: {
        borderRadius: 10,
        height: '60%',
        boxShadow: '0px 2px 1px -1px rgba(0,0,0,0.2), 0px 1px 1px 0px rgba(0,0,0,0.14), 0px 1px 3px 0px rgba(0,0,0,0.12)',
    },
    styledInput: {
        border: '2px solid #e1e8ee',
        borderRadius: 4,
        fontSize: '1em',
        padding: '12px 6px',
        marginBottom: 5,
    },
});

const Login = ({ classes }) => {
    const { loginWithRedirect } = useAuth0();

    return (
        <Card data-cy="authenticationSection" className={classes.root}>
            <Flex width="50%" bg="white" className={classes.card} flexDirection="column" alignItems="center" justifyContent="center">
                <Flex flexDirection="column" flex={1} width={0.75} p="6% 2%">
                    <Flex alignItems="center" justifyContent="center" flex={1}>
                        <Image data-cy="signupSection-logoBlue" width={[0.5, 0.5, 0.3]} src={logoBlue} />
                    </Flex>
                    <Flex flexDirection="column" justifyContent="flex-end" flex={1}>
                        <Button
                            className="signupButton"
                            data-cy="signupSection-button"
                            style={{ borderRadius: 20 }}
                            size="medium"
                            variant="contained"
                            color="primary"
                            onClick={() => {
                                loginWithRedirect();
                            }}
                        >
                            Sign Up / Log In
                        </Button>
                    </Flex>
                </Flex>
            </Flex>
        </Card>
    );
};

export default withStyles(styles)(
    connect(
        null,
        null,
    )(Login),
);

All it has is one button that takes me to my Auth0 login. I cannot navigate to it because of chrome-error://chromewebdata/ and have set "chromeWebSecurity": false.

I have read your best practices and I agree that you should try to programmatically get access but think of your customers going to your app and not being able to log in via the UI that is probably the worst thing that can happen. So it is imperative that we make sure that we are not breaking the UI in the same way that we test everything else. I understand the drawbacks but I am willing to go through them so long as when I know I go into production my users will be able to authenticate.

I hope that this provides sufficient information and I'm happy to provide more to get this resolved.

[jennifer-shehane]

@afrancht We do and have had a reproducible example as given here. https://github.com/cypress-io/cypress/issues/4220#issuecomment-597602768 We however have not been able to determine what is causing this behavior to date.

This issue is not currently in our backlog to address, but I can bring it up with the team to reevaluate if we have resources to dedicate to investigating this.

We understand this is a blocker when attempting to click through a button/link that redirects.

Currently we do recommend programmatically testing login. Testing login flows end-to-end is a current priority of ours that we are planning a multi-step approach for addressing soon.

[ohare93]

Same issue here.

Things I have tried:

1. Setting "chromeWebSecurity: false" as stated here
2. Set the Before Browser Launch options states here
3. Setting Disable Web Security to my Chrome launcher, such as "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --disable-web-security (It happens on all browsers, fyi)

None have worked, issue still persists. Doesn't happen on my colleagues computer.

[ohare93]

If anyone has this error while trying to login to their app with SSO, then see the official Cypress Recipe for logging in via SSO. This has fixed the issue for me 👍 Or perhaps one of the other recipes will help

[ashleypavlik]

@jennifer-shehane
I have simplified our code to provide the best example that you can literally copy and paste to reproduce The first "it" is just going to our website and verifying some elements on the page. The second "it" is just clicking the "login" button on that page and then you will see the chrome error. This has always worked for us up until March 22nd, when it started failing. We had no application code changes OR changes to the cypress test itself in that time frame. Please see below:

describe('TalentMine Login Tests', function() {
    //Splash Page
    it('SplashPage - Verify Page elements', function () {
        cy.visit('https://t.talentmine.com/login');
        //Verify headings
        cy.get('[data-qa="splash-themes"]').contains('Understand your talents');
        cy.get('[data-qa="splash-themes"]').contains('Accomplish your goals');
        cy.get('[data-qa="splash-themes"]').contains('Collaborate with your team');
        //Verify Buttons
        cy.get('[data-qa="splash-login-button"]').should('have.text', 'Log in');
        cy.get('[data-qa="splash-login-button"]').should('have.css', 'background-color', 'rgb(63, 186, 189)');
        cy.get('[data-qa="splash-learnmore-button"]').should('have.text', 'Learn More');
        cy.get('[data-qa="splash-learnmore-button"]').should('have.css', 'background-color', 'rgb(37, 55, 101)');
        cy.get('[data-qa="splash-support-link"]').should('have.text', 'Customer Support');
        cy.get('[data-qa="splash-support-link"] a').should('have.attr', 'href', 'https://community.talentplus.com/');
        cy.get('[data-qa="splash-copyright"]').contains('Copyright ©');
    });
    //Login Page
    it('LoginPage - verify Email page elements', function() {
        cy.visit('https://t.talentmine.com/login');
        cy.get('[data-qa="splash-login-button"]').click();
        cy.url().should('include', 'login?talentMine');
    });
});

Note - not sure why the code isn't formatted correctly, so I attached a screenshot as well. This is very important to our team to get fixed, please provide an update on a solution.

[jennifer-shehane]

What appears to be the case in some of these examples is a presence of an X-Frame-Options header on a separate domain. Normally, Cypress strips these headers for the application under test. But there's an exception.

• We only strip X-Frame-Options from the same domain under test, so a request to a different domain will maintain the X-Frame-Options headers.

This is, in some cases, causing the site to redirect to chrome-error://chromewebdata/

Workaround

Using the Ignore X-Frame headers extension will ignore X-Frame-Options headers and Content-Security-Policy HTTP response headers when installed in the Cypress Chrome browser.

⚠️ Note: These extensions are third party and not created, maintained or monitored by Cypress. You are responsible for evaluating these extensions.

cypress open (Chrome, headed only)

1. Open Cypress using cypress open and click on a spec file to open Cypress via Chrome.
2. Visit https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe and click 'Add to Chrome'
3. Run cypress open as normally, the site under test should now properly redirect.

cypress run (Chrome, headed only)

We'll need to make this extension available via Chrome on any machine, not just the one we locally opened. To do that, we'll load the unpacked extension via Cypress's before:browser:launch API.

1. Visit https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin to download the 'Chrome extension source viewer' extension and click 'Add to Chrome'. (Or any other means you'd like to get an unpacked extension from the Google WebStore)
2. Visit https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe and using the previously installed extension, click 'CRX' then 'Download as zip'.
3. Upzip the extension and place it within your project where you are testing with Cypress.

4. In your cypress/plugins/index.js file, provide the following code, replacing the path with an absolute path to the previously unzipped extension's folder:

   module.exports = (on, config) => {
     on('before:browser:launch', (browser, launchOptions) => {
       if (browser.family === 'chromium' && browser.name !== 'electron') {
         // provide absolute path to unpacked extension's folder
         launchOptions.extensions.push('/Users/jane/Dev/my-app/gleekbfjekiniecknbkamfmkohkpodhe')
       }
   
       return launchOptions
     })
   }
   

5. Run Cypress, specifying the chrome browser (or chromium browser other than Electron), the site under test should now properly redirect.

   cypress run --browser chrome
   

More Issues?

This may not cover all cases of redirects to chrome-error://chromewebdata/. If you're still experiencing this issue after trying the workarounds, please comment with a reproducible example so we can investigate.

Permanent Solution

I'll have to discuss with the team what Cypress would plan as a more permanent, cross-browser compatible solution to this situation. This is obviously something we don't want our users to have to encounter.

We have larger feature work in the works surrounding testing authentication (visiting cross-domain sites) and I will surface this as a factor to consider as part of that work.

[MisterGlass]

Are those extensions included with the prebuilt docker image, and if not is it possible for them to be added in the next version?

On Thu, Jun 25, 2020, 2:42 AM Jennifer Shehane [e-mail]
wrote:

What appears to be the case in some of these examples is a presence of an
X-Frame-Options header on a separate domain. Normally, Cypress strips
these headers for the application under test. But there's an exception.

• We only strip X-Frame-Options from the same domain under test, so a
  request to a different domain will maintain the X-Frame-Options
  headers.

This is, in some cases, causing the site to redirect to
chrome-error://chromewebdata/
Workaround

Using the Ignore X-Frame headers
https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe
extension will ignore X-Frame-Options headers and Content-Security-Policy
HTTP response headers when installed in the Cypress Chrome browser.

⚠️ Note: These extensions are third party and not created, maintained or
monitored by Cypress. You are responsible for evaluating these extensions.
cypress open (Chrome only)

1. Open Cypress using cypress open and click on a spec file to open
   Cypress via Chrome.
2. Visit
   https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe
   and click 'Add to Chrome'
3. Run cypress open as normally, the site under test should now
   properly redirect.

cypress run (Chrome only)

We'll need to make this extension available via Chrome on any machine, not
just the one we locally opened. To do that, we'll load the unpacked
extension via Cypress's before:browser:launch API
https://on.cypress.io/browser-launch-api#Add-browser-extensions.

1.

Visit
https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin
to download the 'Chrome extension source viewer' extension and click 'Add
to Chrome'. (Or any other means you'd like to get an unpacked extension
from the Google WebStore)
2.

Visit
https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe
and using the previously installed extension, click 'CRX' then 'Download as
zip'.
3.

Upzip the extension and place it within your project where you are
testing with Cypress.
4.

In your cypress/plugins/index.js file, provide the following code,
replacing the path with an absolute path to the previously unzipped
extension's folder:

module.exports = (on, config) => {

 on('before:browser:launch', (browser, launchOptions) => {

   if (browser.family === 'chromium' && browser.name !== 'electron') {

     // provide absolute path to unpacked extension's folder

     launchOptions.extensions.push('/Users/jane/Dev/my-app/gleekbfjekiniecknbkamfmkohkpodhe')

   }



   return launchOptions

 })

}

5.

Run Cypress, specifying the chrome browser (or chromium browser other
than Electron), the site under test should now properly redirect.

cypress run --browser chrome

More Issues?

This may not cover all cases of redirects to chrome-error://chromewebdata/.
If you're still experiencing this issue after trying the workarounds, please
comment with a reproducible example so we can investigate.
Permanent Solution

I'll have to discuss with the team what Cypress would plan as a more
permanent, cross-browser compatible solution to this situation. This is
obviously something we don't want our users to have to encounter.

We have larger feature work in the works surrounding testing
authentication (visiting cross-domain sites) and I will surface this as a
factor to consider as part of that work.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/cypress/issues/4220#issuecomment-649264985,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACCTLXLI6LLDRJVH7DMQF3RYLWVZANCNFSM4HNQRQYQ
.

[MisterGlass]

I just tried this workaround and it doesn't seem to do anything, everything still fails. As mentioned before, I only have issues when running cypress within the docker image (I extended the image to include this new plugin) & attempting an auth0 login.

[jennifer-shehane]

@MisterGlass I suspect there may be some other situations that may result in being redirected to the chrome-error://chromewebdata/ issues. Can you provide the code on how you included the extension in the docker image? Or any other code to reproduce the issue you're seeing?

[MisterGlass]

@jennifer-shehane For proof of concept I just downloaded the extension locally and created an dockerfile which extended the premade one and copies the folder in.

FROM cypress/included:4.9.0
COPY ./project/provisioning/cypress-chrome-extensions /cypress-chrome-extensions/ignore-x-frame-headers-source

More elegant would be to download and unzip it in place, which should be possible but I stopped when the proof of concept failed.

Unfortunately, my employer would not be happy with me sharing code to reproduce our bug.

[DallinVan]

@jennifer-shehane I just tried your workaround and it works great for allowing us to login via Auth0 in our e2e tests. Thanks for sharing!

[oliver441]

The workaround that @jennifer-shehane suggests works fine on my Mac. However, it does not seem to work on the linux environment that my CI pipeline uses. (I've double-checked that I am providing the correct absolute path to the extension with the help of the __dirname function. I've also double-checked that headed Chrome is installed and launching, not Electron)

I've also tried the version of the workaround mentioned in issue #1763. Both versions work on my Mac, but not in my CI pipeline.

Has anyone gotten this workaround to work on any linux distros? If so, would you please provide additional datapoints for any steps you had to take?

(@MisterGlass, did you ever get it to work with the cypress/included:4.9.0 image?)

Would love to 1) get the workaround working on linux and 2) see a cross-browser fix for this issue in a future Cypress release.

[MisterGlass]

@oliver441 It seems like we have the same flavor of this bug!

No, I did not have any more ideas once the plugin failed :(

[oliver441]

The workaround still isn’t working for me on my linux image. I'll keep testing/experimenting on my end, but I'm fairly confident that I'm following all of the workaround steps correctly.

It looks like I’m experiencing the same issue that @MisterGlass reported in his April 14 comment earlier in this thread where he said: _“We do not see this running the client CLI or interactive. But we use the cypress/included:4.4.0 docker image to run the tests in CI. I ran my tests from that and was able to reproduce the error locally. So, it works when invoked in my local (OSX Catalina) shell, but doesn't in the docker image.”_

Of the people who said they got it to work — @chepelevdi, @LieAlbertTriAdrian, @DallinVan — did any of you (or anyone else reading this thread) get it running on a linux image? Or was it just a Mac (which we know works)?

With the exception of this issue, my experience with Cypress so far has been great. That said, I won't be able to fully adopt Cypress until I can get this issue resolved. :'( Hoping to find a path forward!

I would appreciate any suggestions for how I can get this workaround up-and-running until a true cross-browser fix is shipped. Thanks!

[valentijnnieman]

After Chrome updated to 84 this morning, the plugin solution stopped working for me. Switching back to Chrome 83 solved it.

[oliver441]

@jennifer-shehane I’m also seeing what @valentijnnieman observed — the plugin workaround does not work on the latest version of Chrome (84.0.4147.89).

The workaround seems to work on some versions of Chrome but not on others. And at least in my case, I have still never been able to get it to work successfully on linux. (Anyone out there get it to work on linux?)

Here are the Chrome versions I have tested so far:

• 84.0.4147.89 — no, workaround does not work. Mac+Linux runs fail with chrome-error://chromewebdata/ message
• 83.0.4103.116 — yes, workaround does work on my Mac. Linux run hangs
• 81.0.4044.138 — no, workaround does not work. Mac+Linux runs fail with chrome-error://chromewebdata/ message
• 80.0.3987.87 — yes, workaround does work on my Mac. Linux run hangs

On Chrome versions 83.0.4103.116 and 80.0.3987.87, the workaround works fine on my Mac, but on Linux the test runs hang forever without actually starting. Any tips/ideas for what might be going on?

[paschalidi]

What appears to be the case in some of these examples is a presence of an X-Frame-Options header on a separate domain. Normally, Cypress strips these headers for the application under test. But there's an exception.

• We only strip X-Frame-Options from the same domain under test, so a request to a different domain will maintain the X-Frame-Options headers.

This is, in some cases, causing the site to redirect to chrome-error://chromewebdata/

Workaround

Using the Ignore X-Frame headers extension will ignore X-Frame-Options headers and Content-Security-Policy HTTP response headers when installed in the Cypress Chrome browser.

⚠️ Note: These extensions are third party and not created, maintained or monitored by Cypress. You are responsible for evaluating these extensions.

cypress open (Chrome, headed only)

1. Open Cypress using cypress open and click on a spec file to open Cypress via Chrome.
2. Visit https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe and click 'Add to Chrome'
3. Run cypress open as normally, the site under test should now properly redirect.

cypress run (Chrome, headed only)

We'll need to make this extension available via Chrome on any machine, not just the one we locally opened. To do that, we'll load the unpacked extension via Cypress's before:browser:launch API.

1. Visit https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin to download the 'Chrome extension source viewer' extension and click 'Add to Chrome'. (Or any other means you'd like to get an unpacked extension from the Google WebStore)
2. Visit https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe and using the previously installed extension, click 'CRX' then 'Download as zip'.
3. Upzip the extension and place it within your project where you are testing with Cypress.

4. In your cypress/plugins/index.js file, provide the following code, replacing the path with an absolute path to the previously unzipped extension's folder:

   module.exports = (on, config) => {
    on('before:browser:launch', (browser, launchOptions) => {
      if (browser.family === 'chromium' && browser.name !== 'electron') {
        // provide absolute path to unpacked extension's folder
        launchOptions.extensions.push('/Users/jane/Dev/my-app/gleekbfjekiniecknbkamfmkohkpodhe')
      }
   
      return launchOptions
    })
   }
   

5. Run Cypress, specifying the chrome browser (or chromium browser other than Electron), the site under test should now properly redirect.
   shell cypress run --browser chrome

More Issues?

This may not cover all cases of redirects to chrome-error://chromewebdata/. If you're still experiencing this issue after trying the workarounds, please comment with a reproducible example so we can investigate.

Permanent Solution

I'll have to discuss with the team what Cypress would plan as a more permanent, cross-browser compatible solution to this situation. This is obviously something we don't want our users to have to encounter.

We have larger feature work in the works surrounding testing authentication (visiting cross-domain sites) and I will surface this as a factor to consider as part of that work.

This solved my issue for both local development and CI/CD. I am working on an os project so please find an example of the code working solution. The steps I followed in addition to @jennifer-shehane's suggestion.

1. For CI/CD we enable the browser to be chrome instead of Electron this makes really a difference since the workaround is only for chrome at the moment https://github.com/dhis2/capture-app/pull/828/files#diff-4544ea583ec25b9579b382134a525f89R21
2. We set the chromeWebSecurity to false. This is also important so that you can be navigated to the different origin https://github.com/dhis2/capture-app/pull/828/files#diff-4e5a69f9c5bdec4c20952d93e2a1827fR7
3. Including the plugin in out codebase and installing it before we run the cypress app to ignore-x-frame-headers https://github.com/dhis2/capture-app/pull/828/files#diff-4bcea4966f5e62ded90298c2b0907445R5

_The links are on a PR atm so please if they get lost in the future ping me and I will make sure I include the right links_

[wesk]

I'm also running into this issue.

Regarding the suggested workaround: the “Ignore X-Frame headers” plugin is under the GPL-3.0 license, which is fairly restrictive. Update: the author of the extension, @guilryder, updated the license to MIT. Thank you @guilryder!

Regarding the Cypress issue itself: is there a rough timeline for when we can expect a fix to be released?

[MisterGlass]

Any updates would be appreciated, at this point my organization is considering alternatives due to our inability to run cypress in CI.

[danielross95]

push

[Hyvjan]

During summer I faced this problem and used “Ignore X-Frame headers” plugin to get around it successfully. Now I noticed it doesn't work any more as it did.

Any update when better fix in Cypress would be released?

[maniyadv]

Upgrading to cypress version - 4.12.1 from 4.9.0 fixed this issue for me.

[ShamiliPrabu]

Still this doesn't resolve running headless.

[softshipper]

The problem is also not solved without headless.

[headfox23]

I finally went over to puppeteer.
Has no issues at all with redirects etc.

Very unfortunate because I liked cypress a lot :(

[muratkeremozcan]

What appears to be the case in some of these examples is a presence of an X-Frame-Options header on a separate domain. Normally, Cypress strips these headers for the application under test. But there's an exception.

• We only strip X-Frame-Options from the same domain under test, so a request to a different domain will maintain the X-Frame-Options headers.

This is, in some cases, causing the site to redirect to chrome-error://chromewebdata/

Workaround

Using the Ignore X-Frame headers extension will ignore X-Frame-Options headers and Content-Security-Policy HTTP response headers when installed in the Cypress Chrome browser.

⚠️ Note: These extensions are third party and not created, maintained or monitored by Cypress. You are responsible for evaluating these extensions.

cypress open (Chrome, headed only)

1. Open Cypress using cypress open and click on a spec file to open Cypress via Chrome.
2. Visit https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe and click 'Add to Chrome'
3. Run cypress open as normally, the site under test should now properly redirect.

cypress run (Chrome, headed only)

We'll need to make this extension available via Chrome on any machine, not just the one we locally opened. To do that, we'll load the unpacked extension via Cypress's before:browser:launch API.

1. Visit https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin to download the 'Chrome extension source viewer' extension and click 'Add to Chrome'. (Or any other means you'd like to get an unpacked extension from the Google WebStore)
2. Visit https://chrome.google.com/webstore/detail/ignore-x-frame-headers/gleekbfjekiniecknbkamfmkohkpodhe and using the previously installed extension, click 'CRX' then 'Download as zip'.
3. Upzip the extension and place it within your project where you are testing with Cypress.

4. In your cypress/plugins/index.js file, provide the following code, replacing the path with an absolute path to the previously unzipped extension's folder:

   module.exports = (on, config) => {
    on('before:browser:launch', (browser, launchOptions) => {
      if (browser.family === 'chromium' && browser.name !== 'electron') {
        // provide absolute path to unpacked extension's folder
        launchOptions.extensions.push('/Users/jane/Dev/my-app/gleekbfjekiniecknbkamfmkohkpodhe')
      }
   
      return launchOptions
    })
   }
   

5. Run Cypress, specifying the chrome browser (or chromium browser other than Electron), the site under test should now properly redirect.
   shell cypress run --browser chrome

More Issues?

This may not cover all cases of redirects to chrome-error://chromewebdata/. If you're still experiencing this issue after trying the workarounds, please comment with a reproducible example so we can investigate.

Permanent Solution

I'll have to discuss with the team what Cypress would plan as a more permanent, cross-browser compatible solution to this situation. This is obviously something we don't want our users to have to encounter.

We have larger feature work in the works surrounding testing authentication (visiting cross-domain sites) and I will surface this as a factor to consider as part of that work.

Thanks for this, it worked for us.

Perhaps this is better though, rather than using the full path. It would work in any CI this way.

Assuming the extension is in Cypress folder:

launchOptions.extensions.push(`${process.cwd()}/cypress/gleekbfjekiniecknbkamfmkohkpodhe`)

[NellyMFB]

Any updates on this ?

[muratkeremozcan]

Any updates on this ?

Afaik, it is something they are considering to have better support for. For now, the post on the workaround using the Chrome extension works wonders. It is great both locally and in CI.