Closed Julien-Marcou closed 8 months ago
@Julien-Marcou That's certainly not intended. We haven't observed this behavior so I wonder if it is something specific with your tests. A reproducible example or a video of the hanging behavior would be helpful. We'll keep an eye on tracking for this.
I am experiencing the same issue in v13.6.0
I am experiencing this issue as well in 13.6.0 When I open a test in test runner it runs correctly, but if I go to VS Code and make a change to the code and save, normally the test will run again in test runner, but it hangs. I have to stop and restart the test every time I make a change to the code.
I have the same focus issue with Cypress 13.6.0 and Chrome 119 but it does not occur when selecting Edge, Firefox or Electron. In my case, saving changes in VS Code still causes the test runner to start over but because the focus was lost, the process stops there.
We are experiencing the same issue after we updated to v13.6.0 The tests are executed in an Azure Pipeline and stop sending out the requests after 2-3 hours of execution. Additionally, the issue @stephenmday and @EllenFr described appears on my local machine, too. We went back to v13.5.1 for now.
NOTE: I think I should mention that we are sending an HTTP request in "beforeAll" hook of each test to ensure that the test environment is initialized correctly. This one specific request is the one that gets stuck.
It's a globally defined "beforeAll" hook in the e2e.ts
I see the same issue with 13.6.0
Does anyone have a clone-able repo that can be used to reliably reproduce this issue? I've tried a few projects, but can't recreate the described behavior, so I wonder if there's something project-specific that I'm missing. A way to reproduce it locally would provide a way forward to diagnose and fix the problem.
I am seeing this constantly when running Cypress 13.6.0 with latest Chrome interactively on Windows.
If the Cypress window loses focus it will hang.
Even if I let it run, it eventually hangs when it gets to some download tests because the browser pops up a tooltip: 'Find your downloads here'.
Steps to reproduce:
cy.get("#some-text-field").type("foo-bar-baz", { delay: 1000 }).blur()
blur
you have plenty of time (about 10 seconds) to click on another window.type
kind of freezes and blur
fails:
cy.blur() can only be called when there is a currently focused element.
Note that in Firefox the text field does not loose focus unwantedly until the Firefox window gets the focus back.
@iomedico-beyer I'm not able to reproduce this behavior from this example still :/
We are looking into the possibility that this issue may be the cause: https://github.com/cypress-io/cypress/issues/28443
If you open devTools after the hang, do you see a message like below?
Uncaught Error: Attempting to use a disconnected port object
Hi @jennifer-shehane and @chrisbreiding , I created a video and captured the test execution incl. 2 scenarios when Cypress gets stuck.
@iomedico-beyer I'm not able to reproduce this behavior from this example still :/
I found something interesting after creating a complete code sample:
it("types into a text field", function() {
cy.visit("https://www.google.com")
cy.get("button:visible").first().click()
cy.contains("English").click()
cy.contains("button", "Reject all").click()
cy.get("textarea").first().type("foo-bar-baz", { delay: 1000 }).blur()
})
I found that I couldn't reproduce my problem here either. So my (specific?) problem seems to be somehow related with the web app I am trying to test. It also is not Cypress 13.6 specific. Happens the same with Cypress 13.0 (don't know about even older).
@jennifer-shehane In my case I only experienced this in a dual monitor setup I think where my editor and Cypress runner window are on different screens. Maybe you can reproduce it that way?
@iomedico-beyer I'm not able to reproduce this behavior from this example still :/
I found something interesting after creating a complete code sample:
it("types into a text field", function() { cy.visit("https://www.google.com") cy.get("button:visible").first().click() cy.contains("English").click() cy.contains("button", "Reject all").click() cy.get("textarea").first().type("foo-bar-baz", { delay: 10000 }).blur() })
I found that I couldn't reproduce my problem here either. So my (specific?) problem seems to be somehow related with the web app I am trying to test. It also is not Cypress 13.6 specific. Happens the same with Cypress 13.0 (don't know about even older).
Hmm... In my case it is definitely related to v13.6 as rolling back to any prior version of cypress does not reproduce the issue.
@jennifer-shehane In my case I only experienced this in a dual monitor setup I think where my editor and Cypress runner window are on different screens. Maybe you can reproduce it that way?
I am also on a dual monitor setup for what it's worth.
What happens in my case is: Let's say Cypress is typing into a text field which represents a date. When it already typed e.g. 2023-0
I click on another window => the text field looses its focus => some Ajax (of the web app I am testing) posts the input to the server. The response of the post request somehow clears the text field (because the date is invalid, I guess) => Cypress can't type in the rest (although it does not complain) and also can't blur (probably because the original text field was replaced by a new one).
So I guess my problem is something very different than what is discussed in this issue and may be related to a general constraint of the open
mode in Cypress or even (at least Chromium based) browsers in general. Am I right? Cypress just can't suppress the focus loss? Is this documented somewhere, btw?
@iomedico-beyer For me, the issue you describe seems to originate from the behavior of the UI component framework you are using in your app. Not really related to the topic discussed here.
@iomedico-beyer For me, the issue you describe seems to originate from the behavior of the UI component framework you are using in your app.
Partly. I think my main problem is that Cypress cannot supress the focus loss which happens when I click on another window. There should not be a focus loss because the simulated user is typing in something, not clicking around. I just want to know if this is documented somewhere and then it's fine for me. @jennifer-shehane Do you know, perhaps?
It's just that I lost almost a week on this until I understood why my tests are so flaky ...
Not really related to the topic discussed here.
I agree.
@jennifer-shehane We've got same issue. Since 13.6, only in Chrome browser, when you get focus out of cypress runner window it hangs without any errors. Also when I try to download a file in a test. it also hangs after the (download) step without any information. (Chrome 119)
Also getting this. New to cypress, but hard refreshes work, because focused on the chrome window. But save in vscode, and it just doesn't run in chrome unless I click over and focus, hard refresh again.
Also, even with the provided sample tests, when running in the middle, if I click out of chrome just to try and see what happens, it instantly hangs the moment I focus away from chrome.
What OS and OS version is everyone using? Just seeing if there's a trend with OS.
MacOS 14.1.1 (23B81)
Windows 10
What OS and OS version is everyone using? Just seeing if there's a trend with OS.
MacOS Ventura 13.3.1
MacOS Sonoma 14.1.2
MacOS Ventura 13.4.1 (22F82)
Windows 10 22H2 (Build 19045.3693)
I am experiencing the same issue in v13.6.1
@jennifer-shehane In my case I only experienced this in a dual monitor setup I think where my editor and Cypress runner window are on different screens. Maybe you can reproduce it that way?
Just tested in single monitor mode (both using MacOS spaces/fullscreen mode and browser and VSCode opened in the same space) and problem also exists there but only in Chrome (v120). Not in Edge, Firefox, Electron or Chrome Canary (v122). So doesn't seem to be dual monitor/space related.
I tried to update to Cypress v13.6.1, but I'm still having this issue.
I don't have any issue when using Cypress v.13.5.1, so the bug must have been introduced by one of this commit https://github.com/cypress-io/cypress/compare/v13.5.1...v13.6.0
I have the problem with Google Chrome Version 119.0.6045.159 (Official Build) (arm64)
when running the tests in headed mode, I don't have the problem when running in headless mode.
It might be related to this specific version of Google Chrome.
I think I found a way to fix this issue. Open a new tab and go to chrome://extensions
. You should see the Cypress extension and you'll likely see that there's a toggle in the bottom right for it that's off.
We're going to work on a solution in Cypress itself to prevent this behavior from happening, but this should hopefully fix it for local development in the meantime.
If you have something that may be disabling extensions, that may also be an issue, but the core of the issue is that the Cypress extension is not enabled. Please let us know why the Cypress extension is not enabled for you (if you're aware why).
The Cypress Chrome extension has a static ID of caljajdfkjjjdehjdoimjkkakekklcck
. This allows Cypress to be added to your allowed extensions for those working under corporate policies that prohibit extensions.
Additionally, you shouldn't have code overwriting to turn off extensions for example:
module.exports = defineConfig({
e2e: {
setupNodeEvents(on, config) {
on('before:browser:launch', (browser = {}, launchOptions) => {
if (browser.family === 'chromium' && browser.name !== 'electron') {
// don't disable our own Cypress extension
launchOptions.args.push('--disable-extensions')
}
return launchOptions
})
},
},
})
@chrisbreiding That's it, thanks!
I can confirm that toggling on the extension fixes my issue.
Do you have any idea why it would only get toggled off for cypress version >= 13.6.0 and not < 13.6.0 ?
I didn't even know there was a cypress extension when chrome was launched 😅 I definitively did not disable it, and I don't have any code in my project that disables it (but I do work under corporate policies)
For us it could be for the same reason as for @Julien-Marcou. Our machines are under corporate policies.
I can confirm also that toggling on the extension fixes my issue.
It's also off for me after 13.6.0 and I do not have any corporate policy on my computer. Tested on my personal Macbook Pro. So it seems to be a bug in cypress that the extension is not enabled.
I can confirm turning extension on works for me with 13.6.1 - machine has corporate policy also
On Wed, Dec 13, 2023 at 5:58 AM Ethan Setnik @.***> wrote:
It's also off for me after 13.6.0 and I do not have any corporate policy on my computer. Tested on my personal Macbook Pro. So it seems to be a bug in cypress that the extension is not enabled. image.png (view on web) https://github.com/cypress-io/cypress/assets/664434/b5cd5362-fd4a-416d-9724-400cb5c36834
— Reply to this email directly, view it on GitHub https://github.com/cypress-io/cypress/issues/28392#issuecomment-1853969324, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGVXQTDOSPLYCQ7DARW36F3YJGYAJAVCNFSM6AAAAAA7X3YC7OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJTHE3DSMZSGQ . You are receiving this because you were mentioned.Message ID: @.***>
Our theory is that Chrome began to show this confirmation dialog whenever a new tab is opened within the Cypress browser in 13.5.0 and that y'all happened to click 'Change it back' instead of 'Keep it' which will disable the extension. This dialog and its function is actually pretty poorly documented though, so this is a theory. Then when we pushed changes to our extension in 13.6 that required the extension - it is already disabled and doesn't function as it should.
Thanks: the recommended fix worked for me. I don't remember seeing the dialog in the image above. So your theory may not always hold. If it helps, i found the extension disabled in 13.5.1 so enabled it. When I upgraded to 13.6.1 it was disabled again so I re-enabled it. That fixed the problem. I didn't know there was an extension, and do not have any code that disables them.
I don't remember seeing that dialog either but it's totally possible that I did dismiss it with the default "change it back" without thinking.
I am also experiencing this issue as well in 13.6.0,13.6.1 and 13.6.2 When I open a test in test runner it runs correctly, but if I go to VS Code and make a change to the code and save, normally the test will run again in test runner, but it hangs. I have to stop and restart the test every time I make a change to the code. Here is a screenshot below
@Hafiz166 did you try this workaround that Chris mentioned above to see if it fixes your issue?
https://github.com/cypress-io/cypress/issues/28392#issuecomment-1852735772
Now it's working Thanks @caseycling 🤝
I'm also having "Your browser is managed by your organization". The Cypress extension isn't even listed.
In Cypress 13.5.1 the commands were executed normally, still without the extension, though.
The workaround described in https://github.com/cypress-io/cypress/issues/28392#issuecomment-1852735772 did seem to resolve the issue for me.
@xxluke The Cypress Chrome extension has a static ID of caljajdfkjjjdehjdoimjkkakekklcck
. This allows Cypress to be added to your allowed extensions when working under corporate policies that prohibit extensions.
Edit: Found the docs for this: https://docs.cypress.io/guides/references/troubleshooting#Allow-the-Cypress-Chrome-extension
We are currently blocked from testing with the latest version of Chrome (v120) in our build pipeline due to #25891. Although fixed in Cypress 13.6.3, we cannot take this version as this issue seriously impacts developer experience. Would appreciate a quick fix for this issue. Thanks!
@blackgrouse The workaround is to manually turn on the Cypress extension as explained here: https://github.com/cypress-io/cypress/issues/28392#issuecomment-1852735772
We know this isn't ideal and we've been actively looking into ways to improve this experience. Not surprisingly, Google Chrome doesn't really offer an automated way for us to override a user's behavior to not allow an extension to take control of the browser, so there isn't a quick way to force our extension behavior to work.
There are some other things we're considering, like making the extension less necessary for users until they want to do an action that would require our extension. But we are working through ideas, so thanks for your patence.
@blackgrouse The workaround is to manually turn on the Cypress extension as explained here: #28392 (comment)
We know this isn't ideal and we've been actively looking into ways to improve this experience. Not surprisingly, Google Chrome doesn't really offer an automated way for us to override a user's behavior to not allow an extension to take control of the browser, so there isn't a quick way to force our extension behavior to work.
There are some other things we're considering, like making the extension less necessary for users until they want to do an action that would require our extension. But we are working through ideas, so thanks for your patence.
@jennifer-shehane Thank you, appreciate you and your team's effort on this. FWIW, I have not edited the extension's permissions but am still seeing this issue.
@jennifer-shehane @chrisbreiding does it possible to identify if the browser is managed by organization? if so maybe adding a banner to cypress app to warning dev its something that will be already a huge help. I am willing to help on this
Current behavior
When I launch my E2E tests on Chrome, if I focus out of the Chrome window, the E2E commands are no longer running, it's hanging there doing nothing.
If I always stay focused on the Chrome window, the commands work as expected.
After focusing out, re-focusing in the window does not make the commands continue/restart.
Might be related to this PR this https://github.com/cypress-io/cypress/pull/28334
Desired behavior
I should be able to run E2E tests while not being focused on Chrome (as before) so I can do something else while the E2E tests are running.
Test code to reproduce
Sorry I don't have time to create a reproduction of the bug for the moment
Cypress Version
13.6.0
Node version
v18.18.2
Operating System
macOS 14.1.1
Debug Logs
No response
Other
No response