-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
feat: Allow cy.visit to visit cross origin sites. #23297
Conversation
Thanks for taking the time to open a PR!
|
Test summaryRun details
View run in Cypress Dashboard ➡️ This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
timeoutId = setTimeout(() => { | ||
this.off(event, handler) | ||
reject() | ||
}, 1000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an error message would be a good idea, even if the caller ends up ignoring it. Just in case this error leaks out somehow, it will be much easier to pinpoint the issue with an error message.
reject(new Error(`${event} failed to receive a response from ${originPolicy} spec bridge within 1 second.`)) | ||
}, 1000) | ||
|
||
this.once(event, handler) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if 2 (or more) of the same event are sent in succession, but resolved in the primary in a different order? Won't the handlers get switched? It might not be a problem with current usage of this, but I worry it's a foot-gun for future uses.
I'd expect there to be a unique ID passed with the message to the primary and it's only resolved here when the same ID is responded to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
UUID is a good idea. Let me work on that.
timeoutId = setTimeout(() => { | ||
this.off(event, handler) | ||
reject() | ||
}, 1000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
with the error now I am wondering if we just want to have a variable like const promisifiedTimeout = 1000
and just use a formatted string for the error so if we change it in the future we just do it it one place.
Co-authored-by: Chris Breiding <[email protected]>
Co-authored-by: Bill Glesias <[email protected]>
Co-authored-by: Chris Breiding <[email protected]>
cy.origin
command with no cy commands may cause subsequent tests to hang. #21300User facing changelog
Additional details
This feature enables users to visit cross origin sites without having to place the visit inside of a cy.origin block
cy.origin
blocks no longer have to immediately follow navigation eventsNavigating to a cross origin page will no longer have up to a 300 ms delay.
'window:load' must now be declared for a cy.origin block before a navigation event occurs.
we also no longer have the long page load timeout when you navigate to a cross origin page but don't follow up with a
cy.origin
blockSteps to test
How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?