Skip to content
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

Redirection breaks out of cypress iframe when a top or parent redirection is made inside an iframe #19234

Open
mathias-vandaele opened this issue Dec 3, 2021 · 7 comments
Labels
existing workaround stage: ready for work The issue is reproducible and in scope type: bug

Comments

@mathias-vandaele
Copy link

mathias-vandaele commented Dec 3, 2021

Current behavior

When clicking on a button (in an iframe) that is triggering a Javascript function that does :

window.top.location.href = <any url>

Cypress breaks out of its iframe and is redirecting to new page.

Desired behavior

the iframe cypress is using should always be considered as the top level window/document and we should not be able to break this behavior.

I provided a very simple repository where you can reproduce the issue

Test code to reproduce

https://github.com/mathias-vandaele/issuecypress

README.md for more information

Cypress Version

9.1.0

Other

I found a way (dirty) to workaround this issue 👍🏼

I check which Js is causing the problem and I execute before opening the page :

cy.intercept('<full Js url>', (req) => {
    req.continue( res => {
         res.body = res.body.replace('window.top.location.href', 'window.self.location.href')
         res.send()
    })
})
@muralinaidud
Copy link

Is this issue resolved ?
@mathias-vandaele mathias-vandaele could you please explain bit more about your workaround ?

@roc
Copy link

roc commented Mar 3, 2023

I found this worked when we were testing a stripe payment flow:

module.exports = defineConfig({
  e2e: {
    experimentalModifyObstructiveThirdPartyCode: true,
...

Docs here:
https://docs.cypress.io/guides/guides/web-security#Modifying-Obstructive-Third-Party-Code

Updates the Sec-Fetch-Dest Metadata header from iframe to document in cases where requests come from the application under test.

@AtofStryker
Copy link
Contributor

@mathias-vandaele have you tried the experimentalModifyObstructiveThirdPartyCode option?

@cypress-app-bot
Copy link
Collaborator

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

@cypress-app-bot cypress-app-bot added the stale no activity on this issue for a long period label Sep 26, 2023
@jennifer-shehane jennifer-shehane removed the stale no activity on this issue for a long period label Oct 4, 2023
@kaloyanBozhkov
Copy link

I found this worked when we were testing a stripe payment flow:

module.exports = defineConfig({
  e2e: {
    experimentalModifyObstructiveThirdPartyCode: true,
...

Docs here: https://docs.cypress.io/guides/guides/web-security#Modifying-Obstructive-Third-Party-Code

Updates the Sec-Fetch-Dest Metadata header from iframe to document in cases where requests come from the application under test.

I tried using this and the stripe checkout flow loads correctly where it should, instead of window.top mode and force-quitting Cypress. Thanks!

@cypress-app-bot
Copy link
Collaborator

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.

@cypress-app-bot cypress-app-bot added the stale no activity on this issue for a long period label Jul 28, 2024
@muralinaidud
Copy link

This issue is still exist

@cypress-app-bot cypress-app-bot removed the stale no activity on this issue for a long period label Aug 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
existing workaround stage: ready for work The issue is reproducible and in scope type: bug
Projects
None yet
Development

No branches or pull requests

8 participants