Cypress CT does not support ressources fetched from relative paths

[fochlac]

Current behavior

Any relative request from inside a component test will include /__cypress/iframe and will therefore be mapped to /__cypress/src/index.html and forwarded to the ct-dev-server. A header is provided including the original request path, however it would be quite hacky to use this to parse the relative path, as it would need to be matched against the test-file it was last called with.

Desired behavior

Cypress should be able to distinguish between the initial request used to kickstart the test-runner that needs to be mapped to the index.html and subsequent relative requests, that need to be forwarded to the dev-server as relative requests.

i.e. a request to ./data/image.png in a test with absolute path c:/project/cypress/component/test.cy.jsx currently resolves to /__cypress/iframe/c:/project/cypress/component/data/image.png but should resolve to /__cypress/src/data/image.png

Test code to reproduce

it('image with relative path should load', () => {
  cy.mount(<img src="./path/to/image.png" />)
  cy.get('img').should('be.visible').then(($img) => {
    expect($img[0].naturalWidth).to.be.greaterThan(0);
  })
})

I have a failing testcase in my custom dev-server here:
https://github.com/fochlac/cypress-ct-custom-devserver/blob/main/cypress/component/Test.cy.tsx#L13-L27

However I have also reproduced the issue using the webpack dev server in an private repository. Since the offending code is in the iframe controller this should also affect the vite-devserver:
https://github.com/cypress-io/cypress/blob/7630caed820c685295ff2fb52c98455ab0cf7bf6/packages/server/lib/controllers/iframes.ts#L44C1-L62

A workaround would be to use the __cypress_spec_path -header and match it against subsequent requests to properly map relative requests to the output folder, but that is super hacky.

Cypress Version

12.x

Node version

16.16

Operating System

windows / unix

Debug Logs

GET /__cypress/iframes/C:/gitHub/cypress-ct-custom-devserver/cypress/component/Test.cy.tsx 304 2.459 ms - 
GET /__cypress/iframes/C:/gitHub/cypress-ct-custom-devserver/cypress/component/data/image.jpg 304 2.484 ms

Other

No response

[fochlac]

@lmiller1990 Have you encountered this problem before / thought about a solution?
As the request url is already mapped to __cypress/src/index.html in the iframe-controller wouldn't it be better to initialize the iframe directly with __cypress/iframe/index.html instead of __cypress/iframe/c:/full/path/to/test.cy.tsx?
That would allow us to recognize any other request in that context as a relative request and we could subsequently proxy it from __cypress/iframe/relative/path.end to __cypress/src/relative/path.end.
Since the request from __cypress/iframe/index.html could still be proxied to __cypress/src/index.html nothing would change for the dev-servers, except that relative urls would work as well. This makes me hope that such a change would not be super invasive.
I did not find the place where the iframe is initialized though, so I might miss some implications of such a change.

[lmiller1990]

Hm, interesting idea - if it's a not breaking change, I think it'd be fine. Are you interested in making a PR? I'd like to see if anything fails.

I will be out on vacation for a few weeks, but I'll do my best to give you some feedback during that time. You could also tag anyone in @cypress-io/component-testing if you need a review.

[fochlac]

I'll give it a try. When I had a closer look I noticed the header is actually parsed from the url, so just dropping it is not possible. However I could move the source into a query-param, sth like __cypress/iframe/index.html?specPath=c%3A%2Fpath%2Fto%2Fproject%2Fpath%2Fto%2Fspec.cy.tsx.

It's not super urgent, I worked around it for now with the header hack and we are migrating to my devserver, but would be nice to see this improved anyway. Also have a great vacation!

[lmiller1990]

@fochlac vacation was good, I will review your PR now, thanks for the patience.

[lmiller1990]

@fochlac merged in #27510. This will be in the v13 release later this month. THANK YOU!

[jennifer-shehane]

The code for this is done, but this has yet to be released. We'll update this issue and reference the changelog when it's released.

[jennifer-shehane]

Released in Cypress 13.0.0.