Redirect URL malformed if # is present

[dwineknott]

Hi @jennifer-shehane ,

Moving this to a new ticket as requested.

Revisiting this, after updating to version Cypress 5.0.0 I'm still getting this redirect error. The message in the cypress client is different now though. You can see the redirect is still resolving to https://app.songtrust.com/__/#add/success/{id} (stripping out the /songwriter/ ).

The test is passing with this error when I run it locally, but fails command line (or in CI). Command line client crashes with "The automation client disconnected. Cannot continue running tests."

I am using experimentalSourceRewriting: true in my config.

Sample code:

describe('Smoke Test', () => {
  Cypress.on('uncaught:exception', (err, runnable) => {
    // returning false here prevents Cypress from
    // failing the test
    return false
  });

  beforeEach(() => {
    cy.server()
    cy.route('POST', 'app.songtrust.com/api/v1/lod/').as('lod');

  });

  it('IMRO ', () => {
    // Begin funnel workflow 
    cy.request({
      method: 'POST',
      url: 'app.songtrust.com/api/v1/user/login/',
      body: {
        username: '[email protected]',
        password: 'testing',
      }
    });
    cy.visit('app.songtrust.com/songwriters/#add');
    cy.findByTestId('show-lod-pros-button')
      .click();
    cy.findByTestId('lod-pro-selections')
      .select('IMRO', { force: true });
    cy.findByTestId('lod-pro-selections')
      .should('have.value', 'IMRO');
    cy.findByTestId('continue-to-form')
      .click();

    /////LOD Form - IMRO///////
    cy.url()
      .should('contains', '/songwriters/#add/lod-form');  //assert URL

    cy.findByTestId('first-name')
      .should('be.visible')
      .type('Frank');

    cy.findByTestId('middle-name')
      .should('be.visible');

    cy.findByTestId('last-name')
      .should('be.visible')
      .type('Ikiseh');

    cy.findByTestId('id_email')
      .should('be.visible')
      .type('[email protected]');

    cy.findByTestId('id_writer_id')
      .should('be.visible')
      .type('01047205098');

    cy.findByTestId('lod-us-representation')
      .should('be.visible')
      .select('ASCAP', { force: true });

    cy.findByTestId('pubco_no')
      .should('be.visible');

    cy.findByTestId('pubco_yes')
      .should('be.visible')
      .click();

    cy.findByTestId('id_publishing_company')
      .should('be.visible')
      .type('Alpha Music');

    cy.findByTestId('publishing_company_pro')
      .should('be.visible')
      .select('ASCAP', { force: true });

    cy.findByTestId('id_publisher_id')
      .should('be.visible')
      .type('697403510');

    //Signature Modal
    cy.get('.type-toggle')
      .should('be.visible')
      .click();

    cy.get('.typed-signature-field')
      .should('be.visible')
      .type('Frank Ikiseh');

    //Submit Form - IMRO
    cy.get('.standard')
      .should('be.visible')
      .click();
    cy.wait('@lod').should((xhr) => {
      expect(xhr.status, 'successfull POST').to.equal(201);
    });
    // Thank you modal - NOT WORKING DUE TO CYPRESS BUG
  });
});

Originally posted by @dwineknott in #1244 (comment)

[dwineknott]

@jennifer-shehane It doesnt appear the issue above is related to #8361 . I've upgraded to 5.1.0 and I'm still encountering this bug.

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

To confirm, you were able to run the sample code I provided without hitting this Webpack Compilation Error?

[bowens-zn]

Confirmed this is the same # in the URL bug as before, just the error is different. Happening in 5.3.0 and 5.5.0.

[jennifer-shehane]

Yeah, I think I may have commented on the wrong issue above actually.

Can anyone provide a reproducible example? The example provided does not reproduce the error and is missing some custom command definitions.

[bowens-zn]

@jennifer-shehane it's interesting. I think it actually might be related to newer versions of Chrome in conjunction with newer Cypress versions. I was able to use Cypress 5.3 and Chrome v69 and can get around this issue now. Unfortunately our code is private and can't be shared but like I've mentioned it's anytime there is a # in the URL which is common for Single Page Angular Applications.

[dwineknott]

@jennifer-shehane I created #8507 after this was closed, which has more detail and an actual reproducible example. We can probably move this conversation there?

[jennifer-shehane]

Duplicate of #8507