misc: Add browser support check and update supported browser messages

[0v00]

• Closes Better message when a supported browser in not found. #28914

Additional details

Current messages for browser support/browser's not found can be confusing e.g.:
Browser: chrome was not found on your system or is not supported by Cypress.
This PR aims to provide clear messaging if a browser is not supported, or if it was not found by name or path.

• If a user enters a browser name or path that does not contain any supported browser names, or does not contain any custom browser (e.g. Brave) names added via Cypress config, then the user will see a BROWSER_NOT_SUPPORTED error message.
• I have added a regex that should cast a wide net for supported browsers - we ideally want to have zero false negatives. If a user enters a browser name or path that is supported (e.g. C:\some\path\msedge.exe) but is not found on their system, they will still see the appropriate BROWSER_NOT_FOUND_BY_NAME or BROWSER_NOT_FOUND_BY_PATH error. However, if a user misspells a browser name e.g. webkitt, or enters an unsupported browser name e.g. arc, they will see the BROWSER_NOT_SUPPORTED error message.
• I have moved the special canary error message to the BROWSER_NOT_SUPPORTED error message.
• getBrowserLauncher() now throws the BROWSER_NOT_SUPPORTED error instead of BROWSER_NOT_FOUND_BY_NAME - if electron or one of the supported browser families is not found, then it should be safe to assume that this browser is not supported.
• I have added webkit to the list of supported browsers in the BROWSER_NOT_SUPPORTED error message.
• Custom browsers added via Cypress config still work and are not filtered out.
• I have updated the BROWSER_NOT_FOUND_BY_NAME error - this error message may still need to be made clearer.
• This PR doesn't take channels into account e.g. passing in chrome:someunsupportedchannel - this will throw a BROWSER_NOT_FOUND_BY_NAME error. I think this behavior makes sense as we want to avoid any false negatives - if the name/path contains e.g. chrome, we can assume it's supported and then throw a more appropriate error later on.
• (Apologies for the number of commits)

Steps to test

Test the following commands:

• yarn cypress:run --browser unsupportedbrowser --project /your/project
• yarn cypress:run --browser badname:channel--project /your/project
• yarn cypress:run --browser /path/to/unsupported/browser --project /your/project
• Run yarn test test/unit/browsers/browsers_spec.js to verify passing tests
• Run yarn test in packages/errors to verify passing tests

How has the user experience changed?

• If a user enters a browser name or path that does not match any supported browser names, or does not match any custom browsers (e.g. Brave) added in via Cypress config, then the user will see a 'browser not supported' error message.

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?

[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.

[0v00]

@jennifer-shehane, recreated this PR as the last one had a messy git history/I made some mistakes when rebasing/merging - apologies for any confusion/extra work on your end.

Thank you for sending @emilyrohrbough 's PR (https://github.com/cypress-io/cypress/pull/28377/files). A few thoughts around adding webkit and electron directly to the knownBrowsers object:

• Does the Electron browser have a binary or a versionRegex? If not, I wonder if it might be better to export it separately in known-browsers with its own type defined in types/src/browsers.ts e.g. export type ElectronBrowser = Omit<Browser, 'versionRegex' | 'binary'>. Otherwise we could make the binary and versionRegex properties in Browser optional and add Electron to knownBrowsers, this would require a few changes in launcher/lib/detect.ts (not sure what else we would have to change).

• The Webkit browser in @emilyrohrbough draft PR conforms to the Browser type, but adding it directly to the knownBrowsers object will require some changes to launcher/lib/windows/index.ts and launcher/lib/darwin/index.ts in order to get the darwin_spec.ts and windows_spec.ts tests passing. Same for Electron.

• Adding these both directly to the knownBrowsers I believe will require some additional changes to browser detection in server/lib/browsers/utils.ts, specifically in getBrowsers()

I think the potential options are:

• add both webkit and electron to known-browsers.ts but exported separately from the knownBrowsers object (and look at properly integrating webkit and electron into knownBrowsers in another PR)
• add them into the knownBrowsers object in this PR (but this PR will get a bit bigger in scope)

I'm not sure if there is a better solution that I'm missing entirely (I could just be overthinking this).

[cacieprins]

Thank you for this PR! I think this is a great start to improving the developer experience with these error messages.

I do think that this change is a great time to combine webkit and electron into the KnownBrowsers list, though, despite the additional scope.

[cacieprins]

Should we note here that webkit support is still experimental?

[0v00]

@cacieprins @jennifer-shehane sorry for the delay, will jump back on the pr this week

[AtofStryker]

Looks like a few system tests need to be updated? https://app.circleci.com/pipelines/github/cypress-io/cypress/60732/workflows/ada99278-62c9-4dbd-bbf1-e49ef1444d99/jobs/2546978/tests#failed-test-2

@0v00 let us know if you need help updating those!