Gathering code coverage from the backend API fails for cross origin tests

[jpierson-at-riis]

Logs and screenshots

  1) Password Reset
       Should navigate to the *** page for a ***:
     SecurityError: Blocked a frame with origin "https://localhost:8381" from accessing a cross-origin frame.
  Error: Blocked a frame with origin "https://localhost:8381" from accessing a cross-origin frame.
      at $Cy.saveCoverageObject (webpack://***-cypress-tests/./node_modules/@cypress/code-coverage/support.js:70:0)

Versions

• What is this plugin's version? 3.10.0
• What is the Cypress version? 13.13.3
• What is your operating system? Windows 10
• What is the shell? Powershell Core 7.4.5
• What is the Node version? v20.16.0
• What is the NPM version? 10.8.1
• How do you instrument your application? swc-plugin-coverage-instrument plugin with NextJS
• When running tests, if you open the web application in a regular browser and open DevTools, do you see window.__coverage__ object? Yes, coverage gathering is working fine.
• Is there a .nyc_output folder? Coverage output is working fine.
• Do you have any custom NYC settings in package.json (nyc object) or in other [NYC config files] no
• Do you run Cypress tests in a Docker container? Yes for our build pipeline but no locally

Describe the bug
When running with code coverage enabled, a test that navigates to a different origin at the end of the test fails in the afterAll section used by the code coverage plugin because it's attempting to access the code coverage API to get backend code coverage details from a page that is outside of the site. Attempts to intercept the coverage API call, the cross origin page request, or to use the cy.origin method have not helped as the failure appears to be in the code coverage plugin code and these attempted fixes don't appear to affect the behavior of the requests made.

Link to the repo
Sorry, closed source repo and no public example yet.

[jpierson-at-riis]

Initial checks show that by upgrading @cypress/code-coverage from 3.10.0 to 3.13.2 may have resolved our initial issue. Whether we are able to assert the cross origin URL without any issue in this case without the same workaround that we had put in place to avoid the cross origin scenario altogether still remains to be seen.