feat: Close and reopen a new tab in between tests to get around a memory leak#19915
Conversation
|
Thanks for taking the time to open a PR!
|
BackgroundToday we currently close the browser in between specs for e2e - which adds a considerable amount of time to the overall run. The desired functionality for CT is to not close the browser and navigate to the new spec URL. Unfortunately, there is currently a memory leak in Unification, and because we use hash based routing - navigating to the new spec URL does not cause a full page refresh, thus building up memory until its fully exhausted. While I expect us to eventually fix the memory leak, we can take a "middle-of-the-road" approach here and utilize this improvement for both e2e + ct, which would be much more consistent. The "middle-of-the-road" approach avoids needing to close the browser in between specs, and we could simply "clear" or "close" the primary tab to ensure that specs start clean. Cypress Today (first spec - with video)
Cypress Today (first spec - without video)
Option 1: Closing the primary tabConsider the experience and technical ramifications of this approach. This may not be a great user experience depending on how long these operations take.
Option 2: Navigating the primary tabWe'd need to have a design for
|
Test summaryRun details
View run in Cypress Dashboard ➡️ Flakiness
This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard |
||||||||||||||||||||||||||||||||||
|
The ordering that has seemed to work best so far for Option 1 (no intermediate url) is:
|
| originalBrowserKill.apply(launchedBrowser, args) | ||
| } | ||
|
|
||
| const criClient = await browserCriClient.attachToTargetUrl('about:blank') |
There was a problem hiding this comment.
It's not clear to me from the names what the difference is between browserCriClient and criClient.
There was a problem hiding this comment.
I have updated the names to pageCriClient to try and highlight the distinction: ab49d53
| this._handleDownloads(pageCriClient, options.downloadsFolder, automation), | ||
| ]) |
There was a problem hiding this comment.
just curious, why move the navigate & download order?
There was a problem hiding this comment.
Both of these can be done in parallel and aren't dependent upon the navigation to occur. It's a slight performance boost.
User facing changelog
Additional details
With this work, we will be changing how run mode works with respect to transitioning from spec to spec. As @brian-mann stated in the comments today we:
We will be changing this so that on step 11 we:
A couple of important points to note:
How has the user experience changed?
PR Tasks
cypress-documentation?type definitions?cypress.schema.json?