fix: normalize test body invocationDetails from stack traces

[astone123]

This PR closes https://github.com/cypress-io/cypress-services/issues/11991

Additional details

There are a few cases where we don't correctly derive the test body invocation details from the stack trace. This PR fixes those scenarios by looking for at eval or at Suite.eval in Chrome stack traces, and lines with anonymous functions in Firefox stack traces. This will allow Cypress Studio and "Open in IDE" features to work in more cases than they did before.

One of these situations is when it has been re-written as itGrep which happens in the @cypress/grep and @bahmutov/cy-grep plugins. This allows us to determine the correct invocation details for the test.

Steps to test

I tested this with the @bahmutov/cy-grep package. Install the package and register it in your support file in accordance with the documentation. Open Cypress Studio by clicking the "edit in studio" button next to a test. Verify that the test content is loaded correctly and you can edit and save the test as expected.

How has the user experience changed?

Users of @bahmutov/cy-grep package can now use Cypress studio as intended

PR Tasks

• Have tests been added/updated?
• [na] Has a PR for user-facing changes been opened in cypress-documentation?
• [na] Have API changes been updated in the type definitions?

---

Note

Trim E2E test stacks to the actual invocation to produce correct invocationDetails, update Mocha integration to pass context, add comprehensive tests, and verify Open in IDE behavior; update changelog.

• Driver:
  • Enhance stack_utils.getInvocationDetails() to trim E2E stacks to the true test invocation (chromium: at eval/at Suite.eval; firefox: first anonymous frame). Adds stackTrimmedToTestInvocation() and exports extended InvocationDetails.
  • Update mocha.ts to pass 'test' to getInvocationDetails in Suite.prototype.addTest.
• Tests:
  • Add E2E spec cypress/e2e/cypress/stack_utils-invocationDetails.cy.ts and CT spec cypress/component/stack_utils-invocationDetails.cy.ts validating invocationDetails across browsers/contexts.
  • Expand unit tests in driver/test/unit/cypress/stack_utils.spec.ts for stack trimming logic (Chromium/Firefox) and non-trimming in CT.
• App (Reporter):
  • Update reporter.hooks.cy.ts to assert correct "Open in IDE" invocation details, including wrapped it cases.
  • Add fixture runner-specs/cypress/e2e/hooks/wrapped-it.cy.js.
• Changelog:
  • Add bugfix note about sometimes-incorrect stack traces used for test invocation details.

^{Written by Cursor Bugbot for commit 08b95ed. This will update automatically on new commits. Configure here.}

[cypress]

cypress    Run #67374

Run Properties:   Passed #67374  •  08b95ed043: test update

Project	cypress
Branch Review	astone123/fix-itgrep-trace
Run status	Passed #67374
Run duration	19m 13s
Commit	08b95ed043: test update
Committer	Matthew Schile
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	13
Pending	1098
Skipped	4
Passing	26689
View all changes introduced in this branch ↗︎

---

Warning

Partial Report: The results for the Application Quality reports may be incomplete.

UI Coverage  45.61%
Untested elements	187
Tested elements	161

Accessibility  97.98%
Failed rules	4 critical   8 serious   2 moderate   2 minor
Failed elements	101

[astone123]

@mschile @mabela416
After looking at fixing this on the cloud side for a bit, I think the best way to handle the grep stack issue is with a solution like this on the app side. We use the invocation details in various places across the app to decide which test to focus in studio mode and other things, so normalizing the stack on the cloud side doesn't fix the issue entirely. Let me know what you think

[mabela416]

I tested it locally and it works

[AtofStryker]

Likely good to reference what itGrep is and where it is coming from (same with above) https://github.com/cypress-io/cypress/blob/develop/npm/grep/src/register.ts#L77. people who aren't familiar with @cypress/grep will struggle to understand what this means.

The other concern I have is that there could be something legitimate in the stack that has itGrep in it that we want to capture but are omitting it here. Or is this only considered when trying to calculate the row/column in the spec file where the error occurred?

[astone123]

Added a comment there. I'm pretty sure this function is specifically used to identify where the test was executed from, so this shouldn't affect anything else. If it does, it'll be limited to use of the grep plugin

[astone123]

@mschile I updated this so that it works for tests with .only as well as tests that are nested in suite definitions

[mschile]

Added a few comments.