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

Cypress CT does not support ressources fetched from relative paths #26725

Closed
fochlac opened this issue May 10, 2023 · 7 comments
Closed

Cypress CT does not support ressources fetched from relative paths #26725

fochlac opened this issue May 10, 2023 · 7 comments
Assignees
Labels
CT Issue related to component testing Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team.

Comments

@fochlac
Copy link
Contributor

fochlac commented May 10, 2023

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
Copy link
Contributor Author

fochlac commented May 10, 2023

@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
Copy link
Contributor

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
Copy link
Contributor Author

fochlac commented May 12, 2023

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!

@marktnoonan marktnoonan added CT Issue related to component testing Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team. labels May 22, 2023
@lmiller1990
Copy link
Contributor

lmiller1990 commented Jun 5, 2023

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

@lmiller1990
Copy link
Contributor

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

@jennifer-shehane
Copy link
Member

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
Copy link
Member

Released in Cypress 13.0.0.

@cypress-io cypress-io locked as resolved and limited conversation to collaborators Aug 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CT Issue related to component testing Triaged Issue has been routed to backlog. This is not a commitment to have it prioritized by the team.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants