-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cypress run doesn't return to command line #815
Comments
We're trying to use Cypress for WordPress's Gutenberg editor and we're experiencing the same issue. (See the travis job here https://travis-ci.org/WordPress/gutenberg/jobs/293142523) |
Hmm, interesting, can we have diagnostic log - if you run cypress with |
@brian-mann could it be timer problem? Because what we usually see after reporting test results is this
|
I tried to run the same tests with Chrome using When I execute the tests with I also see this error on the console: |
I'm having the same issue, how did you guys solve this? |
Use chrome instead of electron as the selected browser 😎 |
I've seen an issue in TravisCI before with it not killing background processes per command. Basically those will continue to keep it open. I'd try splitting up booting + backgrounding your webserver from running the Cypress process to see if that fixes it. |
@brian-mann I just want to precise than It happens locally as well. (MacOS 10.13) |
I found the issue on my end.
If your test has a combined describe/context/it(s) string length larger or equal of 250chars, cypress run hangs on a failed test, never returning to cli, irrespective of the browser.
…Sent from my iPhone
On 6 Nov 2017, at 21:26, Riad Benguella ***@***.***> wrote:
@brian-mann I just want to precise than It happens locally as well. (MacOS 10.13)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Wait, can you put a code block that does this into the issue - so we can reproduce this unexpected bug
…Sent from my iPhone
On Nov 7, 2017, at 09:01, Paul Dan Pruteanu ***@***.***> wrote:
I found the issue on my end.
If your test looks like describe -> describe or context of a description larger than 176chars, cypress run hangs on a failed test, never returning to cli, irrespective of the browser.
Sent from my iPhone
> On 6 Nov 2017, at 21:26, Riad Benguella ***@***.***> wrote:
>
> @brian-mann I just want to precise than It happens locally as well. (MacOS 10.13)
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
// cypress/integration/test.js
describe(`my feature file`, () => {
context(`that has a describe/ context/ it clause(s) which altogether contains
a combined description string length of 250 characters, when your test fails for
some reason or another`, () => {
it(`halts, without showing the error, or returning to the CLI prompt`, () => {
cy.visit('https://www.cypress.io/')
cy.contains('Finally').should('not.exist')
})
})
})
/* `my feature filethat has a describe/ context/ it clause(s) which altogether contains
a combined description string length of 250 characters, when your test fails for
some reason or anotherhalts, without showing the error, or returning to the CLI prompt`
.length == 251. try remove 2 characters from any of the describe/ context/ it, and
the error will appear, alongside with the return to the command prompt.*/
It worths mentioning that if the test passes, the feedback is given, and it successfully returns to the prompt, irrespective of the combined string length. |
For me it happens with Electron headless and describe('Log Viewer', () => {
beforeEach(() => {
cy.visit(Cypress.env('HOST'));
});
it('should open the Log Viewer', () => {
cy.getElementByTestId('log-viewer-tab').click();
cy.getElementByTestId('log-viewer-notice').should('be.visible');
});
}); Both locally on Mac and on Travis. |
Another issue I'm facing is related to beforeunload (#796). <!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
<script>
window.pageRefreshConfirmation = (e) => {
(e||window.event).returnValue = "Are you sure?";
}
window.addEventListener("beforeunload", window.pageRefreshConfirmation)
</script>
</head>
<body>
foo bar
</body>
</html> // cypress/integration/test.js
describe(`beforeunload issue`, () => {
context(`electron browser fails to return to CLI on a page with beforeunload,
even when removing the listener`, () => {
it(`checks foo`, () => {
cy.visit('http://127.0.0.1:8080/')
.then(() => {
cy.window().then(win => win.removeEventListener(
'beforeunload',
win.pageRefreshConfirmation)
)
})
cy.contains('foo').should('be.visible')
})
it(`checks bar`, () => {
cy.visit('http://127.0.0.1:8080/')
cy.contains('bar').should('be.visible')
})
})
}) when running
you hang up, not getting returned to command prompt: If I remove the event listener from index.html: <script>
window.pageRefreshConfirmation = (e) => {
(e||window.event).returnValue = "If you continue, any information you have entered will not be saved.";
}
//window.addEventListener("beforeunload", window.pageRefreshConfirmation)
</script> |
Thanks for your detailed report @paulpruteanu, it allowed me to solve this issue with a small workaround: I simply clear the beforeEach(function () {
cy.window().then(win => win.onbeforeunload = undefined);
}); |
@brian-mann @bahmutov I am also facing this issue in GitLab CI. All the tests are running fine but the control is not returning back to CLI. Is this an issue with Cypress or I am doing something wrong? I have attached a screenshot of this issue. Any help or direction will be greatly appreciated. Thanks! |
I am experiencing the same issue running locally in OS X |
@igor-starostenko-ag Is funny that you posted that screenshot exactly when I was dealing with an issue in electron cause by that prompt |
Unfortunately we have to close this issue due to inactivity. Please open a new issue if there is new information to provide concerning the original issue. |
Current behavior:
does not return to command line, under some circumstances, irrespective of the test results.
Desired behavior:
to return to command line, as the exit code is relevant when creating a build.
How to reproduce:
I could not replicate it, but the sequence of events in GUI is:
VISIT url # containing a hash-bang
XHR GET 200
XHR POST 404
XHR GET 200 # removes part of the URL hash-bang
CONTAINS something
XHR POST 200
XHR POST 200 # that's when the DOM get's updated with something
XHR GET 200
NEW URL # restoring the hash-bang
It works fine in the GUI, on both Chrome and Electron, but it's stuck in CLI with default browser (Electron).
Additional Info (images, stack traces, etc)
The text was updated successfully, but these errors were encountered: