Cypress: Page occasionally does not load from cy.visit()

[drewbrend]

Current behavior:

99+% of the time this is not an issue, but once in a while the cy.visit() at the beginning of a test will not load the page, no matter how long of a timeout I set, no XHR requests are sent, nothing is loaded in the page. This is only ever seen in cypress tests and has never been seen manually by our testers so I am sure it is a bug with Cypress.

CypressError: Timed out after waiting '60000ms' for your remote page to load.

Your page did not fire its 'load' event within '60000ms'.

You can try increasing the 'pageLoadTimeout' value in 'cypress.json' to wait longer.

Browsers will not fire the 'load' event until all stylesheets and scripts are done downloading.

When this 'load' event occurs, Cypress will continue running commands.

Desired behavior:

Always load the page.

Steps to reproduce: (app code and test code)

I realize I am not providing a reproducible example, but it is not triggered by any specific test and is not reliably reproducible. I have seen in other tickets that members of the cypress team have asked for additional logging to be turned on. I would like to turn on additional logging that may help diagnose this and provide you the logs next time this happens.

Versions

Cypress 3.1.3

[jennifer-shehane]

Does this happen during cypress open, cypress run, or both?

[lukeapage]

We also have the same problem - I've been spending alot of time investigating this - I wrote up my findings so far on this issue:

https://github.com/cypress-io/cypress/issues/1311#issuecomment-446329446

but I've definitely ruled out visiting the same url as the cause of the problem - I was about to raise a new issue when I saw this.

I've only ever seen the problem on cypress run but for us (as above) it is approximately 1/200 times that visit fails.

As I say in the link - our server definitely responds with the correct and identical html, but its stalled.

It looks like it is something to do with the way in which the initial result is redirected to the proxy - but my knowledge of the inner workings of cypress are preventing me getting further. I'm happy to add any logging or run a special debug version.

[lukeapage]

I've tried:

1. navigating to a different page first
2. turning on full logging
3. waiting for a second before cy.visit

Is there some way to catch the visit failure and try visiting again?

[drewbrend]

Thanks for the additional info @lukeapage!

@jennifer-shehane cypress run is where we are seeing it most often, because we run that very frequently. I estimate we are averaging 1,000 calls to cy.visit() per day in CI with cypress run, probably more.

I believe I have seen it with cypress open a while ago, but it is very infrequent due to the difference in the amount we run in CI vs local development where one person only runs the few tests they are working on.

[lukeapage]

I’ve ended up solving our problems by retrying :
https://github.com/cypress-io/cypress/issues/1313#issuecomment-409342834

[drewbrend]

That is a decent workaround. I'm hesitant to implement auto retries because it will allow for sloppier test writing. If there was a way to implement it for just this issue I'd be all over it.

[lukeapage]

If there was a way to implement it for just this issue I'd be all over it.

You may be able to - if the cli returns the reason for the failures, you can alter that script to only retry tests where this is the problem.

My plan is that for CI and getting PR approval, I will allow retry. But I also have a scheduled run of 20x on master where I will disable retry. Any intermittant failures coming up from that can then be investigated.

However I am wondering how even that will work out - I've spent alot of time fixing intermittant failures the last 5 days and #695 is a big source of problems (click does not retry the get if the element is not visible) and quite often there are situations where it is very difficult to assert with a should in order to make sure the click definitely won't fail.. thats alot of effort that I am not sure if it is worth it, espescially if the cypress team fix #695 . So far it looks like this issue and that issue are the main causes and everything else is a real app problem that should be fixed.

[drewbrend]

We're in the same situation, one of the commenters on https://github.com/cypress-io/cypress/issues/695 is my teammate. Besides that issue we've been able to fix all intermittent failures with either a cy.route()/cy.wait() or a .should().

Thanks, I may look into modifying the retry script in January - higher priority things right now, then we're shut down for the holidays.

[Wolsten]

I get the same error running on my development computer using MAMP. The error arises in different specs but only when I choose to "Run all specs". The error is somewhat random as different specs fail in different places, though some seem to fail more than others. This is happening where there is a valid target to click() using cy.get() (rather than using cy.visit() to a specific url). I find that the url is always opened correctly when I run each spec individually. I'll take a look at the work around, but it doesn't appear to be ideal.

[drewbrend]

@Wolsten that sounds like a different issue. This issue is about a page not loading from cy.visit(), not cy.get().click().

[Wolsten]

@drewbrend, thanks for the feedback. I tried replacing the get click with visit(url) and I see the same error, it doesn't appear to matter how the url is determined. The test in question runs fine every time I run in isolation but always times out when run in a sequence of tests. The strange thing is going back through the snapshots, the one for the page I requested through visit(url) is correctly displayed and the following get([name=title] succeeds as shown in the attached screenshot.

[Wolsten]

A question about a possible work around. As the specs run without problem individually, is there a "before" command I could use to reinitialise the state of Cypress? I tried putting in a cy.wait(10000) in the "before" block but this didn't help.

[jennifer-shehane]

There may be an intermittent issue involving the page load event, as I myself have this issue with one of our Cypress projects - this is the isolating factor though. I only have it on our Dashboard project, no other project. I've isolated a few instances in the past 6 months from our develop branch:

CircleCI IDs:

16251

15371

14318

13936

8119

Video of failure - looks like the url may have gotten in a weird state before beginning test?
https://dashboard.cypress.io/#/projects/5b79905a-f894-4e91-b60c-fff4d94c218a/runs/47652/specs

Printed errors:

[lukeapage]

@jennifer-shehane you have marked it "needs information" - is there anything we can add? If I were you I would enhance logging, release a new version and then ask for logs of when it occurs again.

[Wolsten]

@jennifer-shehane I suspect that my issue is due to Ajax calls not being fully completed. For example, I update a page via an Ajax call and then click a pre-existing navigation element on the page - but not all new data has been loaded from the Ajax call. This is shown, for example, by tables with only partially drawn new rows in the captured screenshot. I have managed to get a much more stable environment by testing for page elements that should be generated by Ajax commands (I guess this is the right thing to do anyway) and also by extending the "pageLoadTimeout" to 600,000 (this appears to be critical). What would be helpful would be a mechanism to identify exactly which page load url (ajax call) is causing the problem as the error message is often unrelated to the preceding step. If as @drewbrend suspects this is a separate issue would you like me to open a new one to this effect?

[jennifer-shehane]

I also want to make sure everyone visiting this issue is aware of a known issue when calling cy.visit() to a url that you are currently navigated to - https://github.com/cypress-io/cypress/issues/1311

It exhibits the exact same error of timing out waiting for the 'load' event - so ensure this is not the case for you - you likely would not be intentionally visiting the same url twice, but your application may be rerouting and end up visiting the exact url you are already on.

[drewbrend]

@jennifer-shehane I'm not sure if that is the same issue. We are calling .visit() in a beforeEach() block, so it is often visiting the same URL, however:

1) cy.visit() calls are not immediately after one another like that ticket
2) It is far from 100% reproducible, only happens once every _few thousand_ cy.visit() calls
3) We are using Jenkins, not CircleCI

[dsimmer]

Unfortunately I cannot offer much more detail, but we are experiencing this on a Mac - Linux machines run the spec fine every time, but the Mac will always fail at the exact same point.

Essentially the test looks like this:

export const goToLoginPage = () => {
  cy.visit('/', {
    onBeforeLoad: win => {
      win.sessionStorage.clear();
    }
  });
};

describe('Account scenarios', () => {
  it('Users can view their account details', () => {
    // All three run without issues
    [kim, david, keith].map(user => {
      goToLoginPage();
      logInAsUser(user);
      clickAccount();
      verifyAccountDetails(user);
    });
  });

  it('Kim can change her default location', () => {
    // Mac always fails with a timeout here, URL '/' never loads and the browser still shows the previous '/account' path after calling goToLoginPage. Linux works every time so far.
    goToLoginPage();
    logInAsUser(kim);
    clickAccount();
    verifyDefaultLocationDropDown();
  });
});

So essentially we are logging in 4 times and on the Mac the 4th time it will consistently fail to navigate to /. There is nothing really special in any of these tests - a couple of clicks, a wait, type some stuff into a field and check the contents of some inputs. I should also note that it is not on the same url - it navigates from /account to /

[Akshaya0309]

@jennifer-shehane I have to run regression , but once in a while the cy.visit() at the beginning of a test will not load the page, no matter how long of a timeout I set, no XHR requests are sent, nothing is loaded in the page. This is only ever seen in cypress tests and has never been by manual testing.

Now I am not able to run regression due to this issue. Can you please check its blocking whole regression.

given('recruiter is logged in', () => {
  cy.clearCookies();
  cy.visit('/' + '?policy=accepted');
  cy.visit('/werkgever/inloggen');
  Login.typeRecruiterCredentials('');
  cy.submit();
  cy.url().should('include', '/werkgever/uw-account');
});

when('recruiter has no products', () => {
  cy.get('.product-item').contains('Je hebt nog geen producten aangeschaft.');
});

when('recruiter selects a profile', () => {
  cy.visit('/recruiter/kandidaten/zoeken');
  cy.get(':nth-child(1) > .search-result').click();
});

it is not able to download /recruiter/kandidaten/zoeken
please check

[jennifer-shehane]

Hey @Akshaya0309, is there anything printed in the console when opening the devtools?

[mshaaban088]

@Akshaya0309 I hope the recording key is not real

[mshaaban088]

@Akshaya0309 Even after editing the comment, the key still shown in the edit history.
Maybe you can delete the comment and re-comment once again

[Akshaya0309]

Thanks I have deleted the history and update again.

[mattvb91]

related: https://github.com/cypress-io/cypress/issues/1039

[acSpock]

Getting the same issue.

Cypress 3.1.0 - running headless Electron 59

One thing to note is this only occurs when i'm pointing my cypress baseUrl to a non localhost site. ie: my tests all pass when running my app locally but intermittent failure when running against dev/production environments.

At first I discovered certain 3rd party scripts were blocking the page load event that I added to the blocklists in cypress json. This fixed those issues but I have little insight when running headless via network tools to diagnose the issue.

Like others, I can't reproduce a particular test because sometimes they pass and others fail and vice versa.

[lukeapage]

We are also non local.

My plan - see if I can reproduce locally, not in the ci, then hack navigation.coffee to log things and show them on the screen so that the error screenshot tells me what’s wrong - because I’ve never seen this with the ui open

[mattvb91]

@acSpock can you check in your network timeline if you can see the same issue as this with your blacklist: https://github.com/cypress-io/cypress/issues/1039#issuecomment-461761215

[acSpock]

@mattvb91 is there a way to check this in headless electron with logs? I'm blind running in headless.

Update:::

I'm able to get around this error by updating pageLoadTimeout to 180000 in cypress.json - After running the same test 20+ times I notice the place in the flow stalls at random parts of my test. However, even though I can get my tests to pass, they take a few minutes longer than normal.

[Lian1230]

Same thing here, on circleCI, even after upgrading to 3.1.5 that supposed to fix an onLoad bug.

[hinfaits]

We're seeing a similar issue where the pageLoad event does not fire on a redirect after app login (not cy.visit). It happens frequently (>5-10% of the time), but not reliably.

We're running Windows Server 2008 / Cypress 3.1.0 / TeamCity as test runner.

If there's anything we can do to provide more info (logging, etc) then we'd be happy to help.

Edit: this seems to happen only when we run through cypress run in CI. I'm not seeing it when running in using open

[jennifer-shehane]

I'm curious if blacklisting some hosts as laid out in this comment may help the load event fire for some. https://github.com/cypress-io/cypress/issues/1608#issuecomment-384351857

[funatronics]

@jennifer-shehane That actually how I fixed my problem: I blacklisted Google ad and tracking services, and the issue no longer occurred.

[lukeapage]

@jennifer-shehane We don't use any external resources. Also you said that you've seen this error on cypress' own tests?

[hdavidzhu]

Not sure if this helps, but I've seen this much more frequently in Electron than in Chrome. I can even get it to frequently not visit when running locally. I don't have this issue when running the same test in Chrome.

[lukeapage]

@jennifer-shehane How is this awaiting information when you have shown reproductions in cypress' own repos? https://github.com/cypress-io/cypress/issues/2938#issuecomment-448135595
As a paying subscriber is it possible to get any extra help in fixing this issue?
I'm making a feature to investigate and fix this in cypress, but its pretty difficult.. It would probably already had a resolution if someone had added exposed logging that could tell us what the problem is, because then we could run it on our builds, see the error and know what needed fixing.

[hdavidzhu]

For my situation, my suspicion is that the proxy layer is confusing two of my requests as one. I don't have any clear understanding of how it works internally, but my mental model is:

1. The test issues a cy.visit
2. At the same time, another request goes out from my app (somewhat like a race condition)
3. The proxy layer requests the page I want to visit first
4. The visit is tied to the 2nd request
5. Somehow this never resolves visit, and the following iframe replacements don't happen

{
  "url": "/mistaken/path",
  "proxiedUrl": "https://c-8f20b948-7982-4993-b34d-f16eb7f83c58.my.starting.website/mistaken/path",
  "headers": {
    "host": "c-8f20b948-7982-4993-b34d-f16eb7f83c58.my.starting.website",
    "connection": "keep-alive",
    "origin": "https://my.starting.website",
    "x-devtools-request-id": "12482.43672",
    "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Cypress/3.1.5 Chrome/59.0.3071.115 Electron/1.8.2 Safari/537.36",
    "accept": "*/*",
    "referer": "https://my.starting.website/the/referrer/path",
    "accept-encoding": "gzip, deflate",
    "accept-language": "en-US",
    "cookie": "some basic cookie"
  },
  "remoteState": {
    "auth": null,
    "props": { "port": "443", "tld": "co", "domain": "starting" },
    "origin": "https://actual.target.website",
    "strategy": "http",
    "visiting": false,
    "domainName": "my.starting.website",
    "fileServer": null
  }
}

I found this log while using DEBUG=cypress: to run Cypress. When I intentionally prevent any new requests to go out while I issue a cy.visit(), we don't hit this error.

[lukeapage]

In my case it’s not that..
We request a visit outside the local host where the branch is deployed. All our requests and images are mocked - that means we cannot have 2 requests at once.

[hinfaits]

We've blacklisted the hosts linked in #1608 and are still seeing this issue

[orwell1984]

We seem to experience same issue.

See https://travis-ci.org/orwell1984/explorer/builds/516284960 for CI run and https://github.com/orwell1984/explorer/blob/master/cypress/integration/clades_info.spec.js for code.

[coderitual]

It looks like increasing pageLoadTimeout to much higher value might be helpful in seeing what is exactly happening on OS level. Any other ideas?

[davidnormo]

We also have this issue. Is there any update yet?

[jennifer-shehane]

@lukeapage You can always reach out by emailing [email protected] when you're on a paid plan.

Although we have instances of what appear to be this error, it is seemingly random. So when we rerun the tests, they pass.

Tracking down a possible issue is a LOT harder, and sometimes impossible, if it can't be recreated reliably. So, any information that anyone can offer will be helpful.

[julesterrien]

@jennifer-shehane :

seeing this too on

Cypress:    3.2.0                                                                              
Browser:    Electron 59 (headless)

The spec passes when run using cypress open but fails when running in circle (underlying command is ./node_modules/.bin/cypress run --reporter junit --reporter-options 'mochaFile=results/junit.xml' --spec <path-to-our.spec.js>)

The test does has a beforeEach which executes a Command to make an API request. In the .then of that command, we run another to login as a user. We do both of these in most test with no problem.

The test then does the following:

cy.window().then((window) => {
      const hasSeenIntroScreen = window.localStorage.getItem(
        LOCAL_STORAGE_INTRO_KEY,
      );
      // this log is printed 
      cy.log('User has seen Intro screen', hasSeenIntroScreen);
      if (hasSeenIntroScreen) {
        // this cy.visit fails
        cy.visit(`${getUrl()}?step=step1`);
      } else {
        // something else
      }
}

Could it have something to do with cy.window? or with window.localStorage.getItem?

Also to note, the app page shows a confirm alert when exiting (the cy.visit would trigger that). Cypress seems to automatically accept alerts (https://docs.cypress.io/api/events/catalog-of-events.html#Window-Alert) and i'm seeing this when running the test with open but maybe this doesn't work well when running with run. In which case, this could be related to https://github.com/cypress-io/cypress/issues/2118.

I'm able to repro this so let me know what info you need

[julesterrien]

Update: we disabled the window.confirm handler when the test is running in headless/cypress and the test pass so at least in our case this seems to be the issue

[Postavshik]

I having issue with cy.visit() as well but only with Electron browser.. 100% of the time
What are the steps of my application

1. Open users page with cy.visit()
2. Click on user and navigate to user profile
3. Call cy.visit() to open users page again.

At the step 3 users page is never opened.

A small spinner in the URL field is always loading and error of Cypress Timeout :(

UPDATE:
The issue was because of the error with 'beforeUnload' event. This error was in the console. Chrome ignores is, but Electron not. Found a workaround with this code added to support/index.ts

Cypress.on('window:load', function(window) { const original = window.addEventListener; window.addEventListener = function() { if (arguments && arguments[0] === 'beforeunload') { return; } return original.apply(this, arguments); }; });

[pisti2010]

Experiencing the same issue, every hundred calls to cy.visit, some will start failing and then it will resolve itself. It leads to false negative tests.

[flotwig]

@pisti2010 Are you on the latest version of Cypress? We made some changes to improve the reliability of cy.visit in 3.3.0.

[pisti2010]

Yes, I saw that and it is partly why we upgraded to 3.3.1 yesterday, but it has not alleviated the issue, and as far as I can tell from today's tries it made it worse. Please tell me what information I can gather and share to help improve this.

[flotwig]

@pisti2010 Capture complete DEBUG logs of the problem as described here: https://docs.cypress.io/guides/guides/debugging.html#Print-DEBUG-logs Please make sure to obscure any sensitive data like passwords, then share it here.

[lukeapage]

We had this issue intermittently and with 3.3.0 it appears to be gone.

We started an investigation- because we were unable to reproduce locally we made a patch file that modified the built cypress code to emit more logging and then applied that patch before running the tests. We only got a little way in when 3.3 was released and it stopped happening.

@drewbrend I wonder, since you had such similar symptoms to us, whether your problems have stopped?

[drewbrend]

Because of this and some other issues (some ours, some with cypress) we had to implement automatic retries for failed tests. With that plugin we don't see this issue anymore. I can't say for sure if it's still happening or not though.

[nitzel]

@Akshaya0309 if you have found a solution or more details for your problem please let me know here #4383

[pisti2010]

So far changing "pageLoadTimeout" to 180000 has fixed the issue for us. I'm unsure whether it's cypress's fault or ours for the possible loading timeout, but for now this is solved for us.

[GordonTester]

I too have been seeing this issue for several months. I tend to get anywhere between 1 to 3 test failures in every other run or so due to timeout, regardless of how high I configure it.

We have retries running but it's causing the team to loose confidence in the stability of the tests.

I'm running 400+ tests hourly as well as chained to deployments and every time it breaks the build a little part of me dies.

[maxime1992]

Upgrading from Cypress 3.1.5 to 3.3.1, I'm having this issue only on CI for some reason.

And in 100% of the cases, no way to make it work on CI, but all fine locally :man_shrugging:

[flotwig]

@maxime1992 Sorry to hear that. Can you share the debug logs from when you experience the issue? Video would also be useful.

Anyone who is experiencing this issue in Cypress 3.3.1, if you could share complete debug logs from when you experience the issue and video, it would be very useful for debugging.

[mattvb91]

We have had to give up on cypress due to this issue causing our team to loose trust in our tests.

Fingers crossed it can be fixed. This is a game stopper unfortunately for now.

[flotwig]

@mattvb91 Can you share the debug logs from when you experience the issue? Video would also be useful.

What is your OS version/Cypress version?

If you have a reproducible example, that would be amazing too. Would like to get to the root of this issue, but so far I can't reproduce it with the information supplied in this thread.

[maxime1992]

@flotwig I'd be glad to except that I cannot repro locally...
I'll try to see if I can get them from CI.

EDIT:

After trying to push on CI with the debug mode activated... It obviously had to pass for the first time :man_facepalming: ... Will retry until I make it fail now.

[maxime1992]

Ok after a few retry on the whole pipeline I managed to repro with the logs turned on :raised_hands:

This is what it looks like for tests that are passing:

And this is how it looks like when it's failing so that was easy to spot :sweat_smile::

Here's a file containing logs around that issue:

cypress-debug-issue-page-not-loading-relevant-logs.txt

@flotwig let me know if that's helpful :)

[flotwig]

This is great @maxime1992, I'll start digging in. Do you have the entire log by any chance?

[maxime1992]

@flotwig yes, here's the full log

cypress-debug-issue-page-not-loading.txt

[lou]

I have the exact same issue as @maxime1992

When upgrading from 3.2.0 to 3.3.+ one of my tests timeout with this error message Your page did not fire its 'load' event within '60000ms'.

cypress_logs.txt

Let me know if you need further debug logs.

Thanks

[zsalzbank]

I'm getting the same thing too. I increased the timeout as well with no luck. Here are my logs:

error.txt

[flotwig]

Hmm, I was hoping 3.3.2 would fix this issue but doesn't look like it.

@lou @zsalzbank Could you share the spec that reproduces this behavior?

[zsalzbank]

This is only happening for me on CI (CircleCI). Interestingly, if I SSH into the instance and then run the test with the same command, the test does run to completion. I'll try to come up with an example repo.

[lou]

@flotwig

describe('login page', function () {
  beforeEach(function () {
    cy.exec('RAILS_ENV=test bin/rake cypress:fixtures')
  })

  it('sets auth cookie when logging in via form submission', function () {
    cy.visit('/users/login')
    cy.get('input[name="user[email]"]').type('[email protected]')
    cy.get('input[name="user[password]"]').type(`aloha42{enter}`)
    cy.url().should('include', '/users')
    cy.getCookie('_test_session').should('exist')
  })
})

FYI I have the exact same kind of tests (same code) for two other kind of users and these 2 tests work as expected.

[zsalzbank]

So for me, it seems that this was an issue with loading resources on the page. I am testing a react application, and the first request to the page will compile the JS bundle. The first request was always taking much longer than the initial timeout since it is a large application. Subsequent attempts succeed (on the same machine) because the initial request already started the build process.

It seems like it might be helpful for the error message to indicate that there were still some resources loading if the visit doesn't succeed because of resources (and maybe what the resources were). My page itself was loading from the server, but the load event was what wasn't triggering. I realize that the error message indicates that for the most part, but more details would probably help.

[dialex]

We have had to give up on cypress due to this issue causing our team to loose trust in our tests.
This is a game stopper unfortunately for now.

I'm having exactly the same problem. Blacklisting does not behave as expected (issue), which leads to flaky tests, which leads to team distrust.

[FilepCsaba]

Giving my experience with this issue, maybe it helps some people.

For us this was caused by some occasional Exception that was visible only in the console, and this exception was caused by a race condition in our code, which in turn was caused, as far as i can tell, from a smaller number of simultaneous network connections in cypress's Chrome and Electron.
So this can also occur from the website not just Cypress.

[goldylucks]

I have the same problem, and intercepting window:load didn't help

$ client/node_modules/.bin/cypress -v
Cypress package version: 3.3.2
Cypress binary version: 3.3.2

[exan-atsui]

It looks like 3.3.2 did resolve this for us

[mattcrooks]

This is happening 100% of the time on a particular page for us. This only seems to happen when when the page requests confirmation to navigate away.
There is an error in the console:
Blocked attempt to show a 'beforeunload' confirmation panel for a frame that never had a user gesture since its load

Hoping this helps with the diagnosis

This only happens in Electron not Chrome.

[AxSch]

It looks like 3.3.2 did resolve this for us

This seems like the right "fix", went from tests working fine yesterday to completely failing this morning. The moment I update from 3.3.1 to 3.3.2, everything works. Madness.

[lenymo]

I was experiencing similar intermittent cy.visit('/') issues using both cypress run and cypress open with about 30-40% frequency on entirely random tests. It was consistently failing in both headless and headed mode, using both Chrome and Electron.

My tests visit the login screen at the beginning of each test but in some instances the "user" was staying logged in (I only realised this after repeatedly running an entire test suite using cypress open).

I was able to solve the issue by dispatching an existing redux RESET_AUTH action during my cy.seedAndLogin custom command. This ensures no login tokens are stored in redux state between tests and has solved my failing tests.

My issue is probably different to the one described above but I thought I'd share my solution in case it helps anyone else who experiences a similar issue and lands on this ticket.

[mariusbutuc]

Noticing the same undesired(?) behaviour as @mattcrooks has referenced:

Blocked attempt to show a 'beforeunload' confirmation panel for a frame that never had a user gesture since its load. https://www.chromestatus.com/feature/5082396709879808

while running Electron 61, on

$ node -v
v8.11.3

$ cypress -v
Cypress package version: 3.4.1
Cypress binary version: 3.4.1

$ cypress open --project ./
# …

_Update:_ My current understanding is that, in my particular scenario, Cypress sometimes thinks a test keeps running when there are continuous (BrowserChannel, in this case) long-polling requests. Don't know if this is by design. Maybe somebody from @cypress-io can comment in that?

As a workaround, the strategy on our end is to end those requests so that Cypress can fully complete the specific tests.

[jennifer-shehane]

Known beforeload issue

We have found a situation where a Page load may time out if there is an event listener on beforeload on the application under test when running in Electron. This would prevent the page from navigating and timeout on the Page Load.

This error looks slightly different from a cy.visit() error timeout and will display the text below.

CypressError: Timed out after waiting '60000ms' for your remote page to load.

Your page did not fire its 'load' event within '60000ms'.

You can try increasing the 'pageLoadTimeout' value in 'cypress.json' to wait longer.

Browsers will not fire the 'load' event until all stylesheets and scripts are done downloading.

When this 'load' event occurs, Cypress will continue running commands.

When this happens:

This situation could happen if you have code similar to any of the code examples below:

window.addEventListener('beforeunload', (e) => {
  e.returnValue = 'Are you sure you want to leave?'
})

window.onbeforeunload = function(){
  return 'Are you sure you want to leave?';
};

Workaround:

There are 2 possible workarounds.

1. Run your tests in Chrome using the --chrome flag during cypress run or choosing Chrome during cypress open.

OR

1. Add the code below to your support/index.js file. This will prevent the prompts from occurring - and not hang Electron.

Cypress.on('window:before:load', function (window) {
  const original = window.EventTarget.prototype.addEventListener

  window.EventTarget.prototype.addEventListener = function () {
    if (arguments && arguments[0] === 'beforeunload') {
      return
    }
    return original.apply(this, arguments)
  }

  Object.defineProperty(window, 'onbeforeunload', {
    get: function () { },
    set: function () { }
  })
})

Everyone

Please try the workaround code above. If this solves your issue, refer to https://github.com/cypress-io/cypress/issues/2118 if this is your issue for official updates. This seems to be the issue for @mariusbutuc, @mattcrooks specifically.

[RashmiKalpeshChauhan]

I am also facing the same issue. Launching browser is working fine. When I am clicking the "View more market link". it is throwing "CypressError: cy.visit() failed trying to load:"

My code is below:

describe('My firs Test',()=> {
  it('load page',()=>{
    cy.visit("https://www.binance.com/en")
    cy.xpath("//a[text()='View more markets']").click();
    cy.wait(50000);
  })
})

Getting the below error:

CypressError: cy.visit() failed trying to load:

https://www.binance.com/en/trade/ETH_BTC

We attempted to make an http request to this URL but the request failed without a response.

We received this error at the network level:

Error: Parse Error

Common situations why this would fail:

• you don't have internet access
• you forgot to run / boot your web server
• your web server isn't accessible
• you have weird network configuration settings on your computer

The stack trace for this error is:

Error: Parse Error
at TLSSocket.socketOnData (_http_client.js:451:22)
at TLSSocket.emit (events.js:194:13)
at addChunk (_stream_readable.js:296:12)
at readableAddChunk (_stream_readable.js:277:11)
at TLSSocket.Readable.push (_stream_readable.js:232:10)
at TLSWrap.onStreamRead (internal/stream_base_commons.js:165:17)

[RiZKiT]

I am also facing the same issue.

I don't think so. The live domain you are testing returns the x-frame-options: SAMEORIGIN header, which prevents that a page is loaded in an iframe.

Cypress uses an iframe to load tests. IMHO you will not be able to test this page in Cypress, unless you are able to modify the return headers and/or use a non-live version of the page, which is normally the better option anyway.

[krawetko]

This issue is giving us random build failures on random tests. This does not happen very often - maybe once every 30 builds (more often when the infrastructure is under heavy load). On the video the page is loaded normally, the XHRs have completed - it just stays at cy.visit step and eventually fails with Your page did not fire its 'load' event within '60000ms'. .

Would it be possible to catch this and re-execute the test?

[jmitchell38488]

@drewbrend great pick up. Was using the same approach but you're right about the intermittent issue when using cy.visit inside a beforeEach call 👍

[clarisights-sharanya]

@jennifer-shehane The same issue occurs to me more often. Is there a way to capture the error and visit the page again?

[pratik-chakravorty]

Experiencing the same issue but the strange thing is that the tests are all running fine locally but on CI it fails every single time.
I am using a docker container where I run the tests on my CI build in Jenkins. I am using cypress run --browser chrome. I have xvfb installed in my container along with all the necessary dependencies. I am stuck here completely trying every possible thing to resolve this issue for the past 5 days now. Nothing seems to be working. Any help would be greatly appreciated.

[clarisights-sharanya]

Experiencing the same issue but the strange thing is that the tests are all running fine locally but on CI it fails every single time.
I am using a docker container where I run the tests on my CI build in Jenkins. I am using cypress run --browser chrome. I have xvfb installed in my container along with all the necessary dependencies. I am stuck here completely trying every possible thing to resolve this issue for the past 5 days now. Nothing seems to be working. Any help would be greatly appreciated.

@pratik-chakravorty try setting --ipc=host if you're Docker, that will resolve the issue. If Kubernetes create a pod with spec hostIPC: true. If not both, can you be specific what's your CI comprises of?
Pls refer this for more info: #350

[jennifer-shehane]

@RashmiKalpeshChauhan I'm not able to reproduce this issue in 3.8.3, please try upgrading.

We will be closing this issue.

There is one known issue provided in this long thread which is related to https://github.com/cypress-io/cypress/issues/2118 - If you have an onbeforeunload with an alert (or confirm, etc) then a timeout on page load will occur in Electron Please see the workarounds detailed here: https://github.com/cypress-io/cypress/issues/2118#issuecomment-580095512

Every single other mention of this issue happening has not provided a reproducible example so we have no path forward to investigate.

If you are seeing the exact same error as below:

1. Update to the latest version of Cypress - your issue may be fixed.
2. This may be this issue: https://github.com/cypress-io/cypress/issues/2118 Please comment there.
3. If the 2 steps above do not address your issue, open a new issue with a completely reproducible example that we can run on our machines. Any issues opened without a reproducible example will be closed as there is no path forward for us to investigate.