feat: Passing --browser flag alone will launch after test selection

[raygdev]

• Closes issue 22003

Additional details

• This was a feature request made in the issue listed above
• When the --browser flag is passed alone, after selecting the testing type, the selected browser will automatically launch.
• I used the localSettings field in the OpenBrowser query to check if the browser was set in the cli. That query was passed as a prop to OpenBrowserList and used on mount and emits the already defined launch function if the browser was set.

Steps to test

In development yarn cypress:open --browser <browser-name-or-path>. Select your testing type in the GUI. After testing type selection, the browser specified will automatically launch. Clicking switch testing type will navigate back to select another testing type. When a new type is selected the user will have to select the browser from the UI. If an invalid browser name or path is passed, the cached browser will not launch and the error will show as intended. The user will either have to select from the list of available browsers or relaunch from the cli.

How has the user experience changed?

Previously, when a user only passed the --browser flag, they would still be prompted to select the browser and click the Start testing in <browser-name> button to open the browser. The only other option was to pass a testing type flag and browser flag together to automatically launch.

PR Tasks

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

[CLAassistant]

All committers have signed the CLA.

[cypress-app-bot]

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.

[raygdev]

Currently the way the code is, when running the command yarn cypress:open --browser chrome it launches as intended. Let's say we provide a browser that isn't on the list like yarn cypress:open --browser something. The warning shows as intended, however... the last cached browser still launches even though a warning, about the browser passed not being found, is displayed. I'm wondering what the outcome should be for this. Should we still allow launch of the cached browser for convenience, and let the user dismiss the warning? Or do we want to negate launching altogether if an incorrect or unsupported browser is passed?

[marktnoonan]

Currently the way the code is, when running the command yarn cypress:open --browser chrome it launches as intended. Let's say we provide a browser that isn't on the list like yarn cypress:open --browser something. The warning shows as intended, however... the last cached browser still launches even though a warning, about the browser passed not being found, is displayed. I'm wondering what the outcome should be for this. Should we still allow launch of the cached browser for convenience, and let the user dismiss the warning? Or do we want to negate launching altogether if an incorrect or unsupported browser is passed?

My suggestion is that if we couldn't find the browser that was passed, we should not open any browser and let you see the warning, then you'd have to either relaunch passing in a different browser name, or pick the browser you want from the list.

[raygdev]

I'm going to open this PR as ready for review so that I can get some feedback on the current code I have.

• I set up a global launch count in ProjectActions to keep track of launchProject calls.
• I exposed the launchCount with a setter to help with testing.
• I used gql-LocalSettings to add a globalLaunchCount field and isValidBrowser field
• isValidBrowser uses what I believe to be a utility function to find a valid browser by name or path and throws otherwise
• I created a new query in OpenBrowser.vue that makes a network request (the values were cached which made globalLaunchCount always evaluate to 0 even though it was updating on the server) so that the launch function wouldn't be called again when navigating back and selecting a new testing type.
• I used the OpenBrowser_LocalSettingsDocument generated from the additional query to keep the request size as small as possible while leaving the other values cached.
• Created a launchIfBrowserSetInCli function that uses the three fields needed and uses the already defined launch function if the conditions are met and is called on mount of the OpenBrowser component.

Since there is already a function that launches with the same values (testingType, wasBrowserSetInCli) I had to create a launch count to keep track of the calls to ensure that both functions wouldn't be called since they rely on the same values. I honestly feel like this is a bit hacky, so I will happily take some advice if changes need to be made. This is my first contribution to a large codebase, so I want to be sure that this is going in the right direction before I code myself into a corner. I will put this back in draft (if need be) after any feedback provided.

[jennifer-shehane]

@raygdev I'll see if the team has some time to review this next iteration.

[raygdev]

@jennifer-shehane sounds good! Thank you!

[marktnoonan]

@raygdev I hit that "update branch" button for you, it seems like there's now a little bit of cleanup needed in the changelog just FYI

[raygdev]

@marktnoonan Done! Thanks Mark!