cypress: Chrome hangs on application open intent with --waiting for new page to load--
Current behavior:
Cypress waits indefinitely for window prompt
Desired behavior:
Testing commands should continue to execute regardless of the opened window
Test code to reproduce
Given we have an html defined using react (not using jsx to make it easier to run in a generic environment)
ReactDOM.render(React.createElement(
'a', {href:"vscode://someurl", 'data-cy':"testing-app"},
"TESTING CYPRESS"
), document.getElementById('main-container'));
or in HTML
<a href="vscode://someurl" data-cy="testing-app">TESTING CYPRESS</a>
The follow test fails to pass
it('does not work', () => {
cy.visit('/')
cy.get('[data-cy="testing-app"]').click();
cy.get('[data-cy="testing-app"]').should('exist');
});
Versions
Cypress: 5.10.0, 4.10.0 MacOS: Catalina 10.15.6 Browsers: Chrome 84
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 20 (6 by maintainers)
I’m referring to this as it is a real blocker for testing business applications. Let’s consider a typical scenario:
A (base url for Cypress tests) -> B (OAuth login form) -> A (redirect uri for OAuth). A and B don’t share the same site.
Note that:
disableWebSecurity = true
I have to hackX-frame-options
using a Chrome extension for fixing “Refused to display ‘https://login.provider.com’ in a frame because it set ‘X-Frame-Options’ to ‘deny’.” This happens because Cypress loads the application into an iframe. Unfortunately, I’m not allowed to load the according Chrome extension due to a corporate policy.)With the following test, I can navigate to the OAuth login form hosted on domain B (meaning: I can see the rendered page):
however, then I also see this warning
If I manually finish the OAuth flow using valid credentials (of course I have to do it within the timeout) then the state of that line turns to
The state of the application is correct, I successfully finished the OAuth flow and the application has a correct state.
But Cypress shows this error:
The stacktrace is:
I think some of the Firefox preferences could fix it. Do you know what is the counterpart of
disableWebSecurity
when running Firefox? I found https://bugzilla.mozilla.org/show_bug.cgi?id=1039678 which is still open but I assume that some combination of FF preferences could provide the same behavior.