"Webpack Compilation Error - multi" on redirect

[dwineknott]

@jennifer-shehane Upping this again. I've upgraded to 5.2.0 and I'm still encountering the below error.

The path in the error: "Users/dknott/Desktop/redacted" is the parent directory for my local Cypress project.

Originally posted by @dwineknott in #8407 (comment)

[dwineknott]

#8407 for reference and code to reproduce.

[bahmutov]

Could you please create a public repo with all code reproducing the error?

[dwineknott]

Hi @bahmutov, and thank you. This repo should generate the error on 1st try:

deprecated

Please run the spec "US_LODapp-smoke.js". You'll need to modify the project folder to your local settings.

The project baseURL is directing the test to one of our public accessible environments, leveraging dummy data.

[bahmutov]

I hit the error, very interesting case

It seems the redirect somehow goes to our spec iframe URL, causing another Cypress runner to load.

[bahmutov]

@dwineknott do you know how inside the application the redirect to the artist page happens? After you add I believe it goes to /add/success/<ID> - but what is the code that actually does the redirect? Is it window.location = or something else? It would give us an idea of where the thing goes sideways.

[dwineknott]

@bahmutov

Below is the the block from our codebase. Note the "else" statement which is where window.location is set:

lod_success: function(response) {
        var d = Date();
        this.hideValidating();
        st.track.safeTrack(st.track.events['manage-songwriters-add-9'], {
            name:response.songwriter.full_name,
            PRO:response.songwriter.pro.name,
            Email:response.songwriter.email,
            type:"LOD Application",
            date:d,
            status:"SUCCESS"
        });

        if (ab_test_value == 1 && response.songwriter.managed_by.songwriters_used == 1) {
            this.showOnboardingModal();
        } else {
            this.reset();
            $('.nav-container .song-nav-section').show();
            window.location = '#add/success/' + response.songwriter.id;
        }
    },

[bahmutov]

@flotwig can you see how the window.location = redirect is acting weird here?

[flotwig]

@bahmutov yeah, does experimentalSourceRewriting help any?

[dwineknott]

@flotwig it hasn't helped on my end.

[github-ronk]

In our company we're looking at migrating from another framework to Cypress. This issue here started to occur very frequently. Looks like some race condition? In any case, this is seriously thwarting our migration. Most of the time, tests fail because of this.

[themosaeed]

hello,
i`m having the same issue. you can find the code below to reproduce it. the problem is that a lot of websites now use this dynamic routing and it needs to be supported. hope you can fix it soon.

here you can find that i went to the registration page directly but it gives the same error even if i went from the main page to the authentication page

note : i`m running version 5.4.0

const inputRegister = 'input[name=email_create]'
const registerBtn = '#SubmitCreate'

context('register new user', () => {
  beforeEach(() => {
    cy.visit(
      'http://automationpractice.com/index.php?controller=authentication&back=my-account'
    )
  })
  it('go to register page', () => {
    cy.get(inputRegister).type('[email protected]')
    cy.get(registerBtn).click()
  })
})

[Urszulasu]

@bahmutov have You any idea how resolve this problem?

[bijojoseph99]

I hit the error, very interesting case

It seems the redirect somehow goes to our spec iframe URL, causing another Cypress runner to load.

Hi,
Is this problem got fixed?
I get the same error.
Could you please help me to fix it.
Thanks

[bowens-zn]

Hitting this error in 5.5.0

[bowens-zn]

PSA, I'm able to get around this by restructuring my tests. If your are ok splitting whatever test you have into 2, just go into a new test right after the point where this error occurs. For example

• Test case 1: it()
  • Test step 1
  • Test step 2 -- IF THE TEST BREAKS HERE
  • Test step 3

Split it into 2 test cases:

• Test case 1: it()
  • Test step 1
  • Test step 2 -- The error will still occur but won't fail the test.
• Test case 2: it()
  • Test step 3

You can then use context() to group these 2 test cases together.

Of course it would be great to fix this but just putting this out there as a hack in the meantime.

[bijojoseph99]

Hi,

This is so frustrating to get this error for no reason.

Just to check this I have made a new test file named "registraionTests.spec.js" and added this simple registration test. The baseUrl "http://automationpractice.com" is provided under the "cypress.json" file and added the following code in the test file, which is actually going to the baseUrl first, then clicking on the "Sign in" link and then adding a unique emailId and then clicking on the "Create an account" Button. It actually takes the test to the registration page to fill the personal details then immediately redirects and gives the "Webpack compilation error".

describe('Registration Feature', () => {    
    it('Register a User', () => {
        cy.visit('/index.php')
        cy.get('.login').contains('Sign in').should('be.visible').click() 

        cy.get('form').within(($form) => {                       
            cy.get('#email_create').type('abcxyz123dkjhkjsdhgkjdshjgd' + '@gmail.com')
            cy.get('#SubmitCreate').click()                           
            })
    })
})

The above test won't fail as there is no assertions, but takes me to the webpack compilation error page.
Can someone please help me to fix this.

Thanks

[mysticdevx]

Using version 5.6.0 and have still the same problem.

[ooge0]

Hi,

This is so frustrating to get this error for no reason.

Just to check this I have made a new test file named "registraionTests.spec.js" and added this simple registration test. The baseUrl "http://automationpractice.com" is provided under the "cypress.json" file and added the following code in the test file, which is actually going to the baseUrl first, then clicking on the "Sign in" link and then adding a unique emailId and then clicking on the "Create an account" Button. It actually takes the test to the registration page to fill the personal details then immediately redirects and gives the "Webpack compilation error".

**describe('Registration Feature', () => {
it('Register a User', () => {
cy.visit('/index.php')
cy.get('.login').contains('Sign in').should('be.visible').click()

    cy.get('form').within(($form) => {                       
        cy.get('#email_create').type('abcxyz123dkjhkjsdhgkjdshjgd' + '@gmail.com')
        cy.get('#SubmitCreate').click()                           
        })
})

I had simple example when Cypres can't reach a requested URL because it can't do this in general.
Why... ? Because you auth flow is related to redirection to another domain and main problem is

The issue with Cypress is when the browser redirects to another 
domain URI for authentication it breaks. 

Why does Cypress break?
Simply because these redirect URIs have a strict Content-Security-Policy (CSP) directive where the iframe property `ancestors` is set to `none`.
Since Cypress works inside an iframe it breaks because of the CSP directive.

SOURCE
All answers here or you can build your internal solution based on the implemented authorization logic for your test app.

[mysticdevx]

SOLUTION: to get rid of the problem, add below values to Cypress.json file

"modifyObstructiveCode": true,
"experimentalSourceRewriting": true

P.S: "experimentalSourceRewriting": true creates crash problem on some environments while running through cypress run command. If you use cypress open then it works fine. If anyone finds walkaround for this, I will be happy :)

[bijojoseph99]

Thanks @mysticdevx
It finally worked adding those couple of values to cypress.json file as you mentioned.
Thanks a lot once again.

[dwineknott]

Yes I shared this higher up in this thread. experimentalSourceRewriting is not addressing my specific case/example.

I think this workaround may not work in all cases however and there are some other bugs associated with experimentalSourceRewriting.

[pebogdan]

This issue is still reproducing. I try on this site https://rahulshettyacademy.com/seleniumPractise/#/ . In this moment I use Cypress 6.2.1. Here is my Code in order to reproduce:

describe('My Second Test Suite ', () => {
    it('My First Test Case', () => {
        cy.log("Go to url")
        cy.visit("https://rahulshettyacademy.com/seleniumPractise/#/")

        cy.log("Enter text")
        cy.get('.search-keyword').type('ca')

        cy.log("Wait for page to load")
        cy.wait(2000)

        //as() is allias command to replace in one variable- declare one to multiple use
        cy.get(".products").as("productLocator")

        //Parent child chaining with assertion
        cy.log("Assert the products list")
        cy.get("@productLocator").find(".product").should("have.length", 4)

        //Iterate from parent to the child and make an if to compare text and add what product we want
        //Iterate over an array of web elements
        cy.get("@productLocator").find(".product").each(($el, index, $list) => { 
            const textReach = $el.find("h4.product-name").text()
            cy.log("Product Name " + textReach)
            if(textReach.includes("Cashews")){
                $el.find("button").trigger("click")
            }
        })

        cy.get(".brand").should("have.text", "GREENKART")  

      //Use then() function in order to save something in a variable and print log in web 
      cy.get(".brand").then(function(logoelement){
        cy.log(logoelement.text())
      })

      cy.log("Click on the bag")
      cy.get('.cart-icon > img').click()

      cy.log("Click Proceed to checkout")
      cy.contains("PROCEED TO CHECKOUT").click()
    
      // cy.contains("Place Order").click()

    })

    it("My second Test case", () =>{
        //Assert if logo text is displayed correctly
      
    })
  })

[mrpimpita]

SOLUTION: to get rid of the problem, add below values to Cypress.json file

"modifyObstructiveCode": true,
"experimentalSourceRewriting": true

P.S: "experimentalSourceRewriting": true creates crash problem on some environments while running through cypress run command. If you use cypress open then it works fine. If anyone finds walkaround for this, I will be happy :)

Excelente!! Thank 👍

[kapelo]

SOLUTION: to get rid of the problem, add below values to Cypress.json file

"modifyObstructiveCode": true,
"experimentalSourceRewriting": true

P.S: "experimentalSourceRewriting": true creates crash problem on some environments while running through cypress run command. If you use cypress open then it works fine. If anyone finds walkaround for this, I will be happy :)

This worked for me. Thanks @mysticdevx

[grimjack]

Is there any update to this issue? I am facing the same error where the cypress runner is getting confused. in my case, the setting the two flags is not fixing the issue. As another datapoint, the same tests run successfully with Cypress version 5.5 and just the experimentalSourceRewriting set to true (This is needed as we use a CDN with SRI).

[dwineknott]

@flotwig or @jennifer-shehane Any updates on this bug?

[abhishekpatil173]

Hi guys! I am facing the same issue. I am using Cypress version 6.4.0 and I need to run the tests in headless mode. Are there any updates regarding this? @flotwig @jennifer-shehane

[RicardoFernandes8]

Is there any update to this issue? I am facing the same error where the cypress runner is getting confused. in my case, the setting the two flags is not fixing the issue. As another datapoint, the same tests run successfully with Cypress version 5.5 and just the experimentalSourceRewriting set to true (This is needed as we use a CDN with SRI).

Good afternoon, I've got exactly the same defect reported here, and using the two attributes below doesn't solved the defect.
"modifyObstructiveCode": true,
"experimentalSourceRewriting": true

[dmitrykazakov]

@RicardoFernandes8 I've got exactly the same issue too, the two attributes don't solve it. Any ideas?

[VladimirCores]

Super annoying problem, it happens from time to time, take a lot of time!

[rodrigovolkmer]

I am also facing the same problem.

and using the two flags above makes the home page where I need to go to show up in a completely broken state:

[MaliYurt7]

@RicardoFernandes8 , actually, for this issue I placed "experimentalSourceRewriting": true and my problem has been solved.
PS: my chrome version is 89.0.4389.90 , electron 87,firefox86 and "cypress": "^6.8.0".

[Sajadu1994]

G

[vishall]

SOLUTION: to get rid of the problem, add below values to Cypress.json file

"modifyObstructiveCode": true,
"experimentalSourceRewriting": true

P.S: "experimentalSourceRewriting": true creates crash problem on some environments while running through cypress run command. If you use cypress open then it works fine. If anyone finds walkaround for this, I will be happy :)

Thank you so much for your help

[vishall]

Very fustrating experience with cypress which is stopping my ci to go green with this issue

[victorio1]

SOLUTION: to get rid of the problem, add below values to Cypress.json file

"modifyObstructiveCode": true,
"experimentalSourceRewriting": true

P.S: "experimentalSourceRewriting": true creates crash problem on some environments while running through cypress run command. If you use cypress open then it works fine. If anyone finds walkaround for this, I will be happy :)

Thanks!!!!!

[bowens-zn]

+1 still happening in 7.0.0

only happens when clicking the save button on our site, which leads to the malformed URL issue ( # -> __ ). the suggested workarounds have no effect.

@jennifer-shehane please take another look at this when you get the chance, this is blocking our test strategy.

[jennifer-shehane]

I'm no longer able to recreate this bug from any of the previous code examples provided.

I see people are still reporting the issue. I was hoping to see if this upcoming fix would fix the issue #15995 but am unable to confirm since there are no reproducible examples in this thread.

Reproducible example

Please provide a reproducible example that we can run to see this issue.

[jandresboyaca]

@jennifer-shehane Do you know when will be released this fix?

[dwineknott]

@jennifer-shehane Confirming the release of 7.3.0 fixed this issue for our team.

Related merge:
#15995

[bowens-zn]

@jennifer-shehane Verifying this is fixed in our implementation in 7.3.0. Huge kudos to the team for tracking down and fixing this nearly impossible to reproduce bug.

[Rao-J]

@jennifer-shehane , this issue still persists

Cypress package version: 7.4.0
Cypress binary version: 7.4.0
Electron version: 12.0.0-beta.14
Bundled Node version:
14.15.1

/// <reference types="cypress" />

describe('Login Test', () => {
    it('Visit app server', () => {
        // visit app server 
        cy.visit('https://SomeLink.html')

    })

    it('Enter credential', () => {
      // type user name
      cy.get('#username')
        .type('Value1')
        .should('have.value','Value1')

      // type user name
      cy.get('#password')
        .type('Value1')
        .should('have.value','Value1')
    })

    it('Click login botton', () => {
      // click login button
      cy.get('.btn-submit').click()
      // check if login
      cy.get('#userdisplay-btnInnerEl').should('contain','Value')
    })

  })

[GuriKristine]

Hi, our team had this exact issue and it turned out to be due to frame busting / frame killing implemented. I.e. our application doesn't accept being run inside a frame (which is what Cypress does). When the application detects the framing, our application forces itself to top location using a window.top.location.replace([...]).

[rogoit]

"experimentalSourceRewriting": true

Works for me thx for zour passion @jennifer-shehane