fix: match alternate edge version string format

[CarbonCollins]

• Closes Cypress not finding beta/dev builds of Edge on linux #25455

User facing changelog

Additional details

Edge was returning an alternate format for its version string which meant the browser detection version regex was not matching. This change allows the regex to match on both the original form and the new format which switches the version number and channel places arround.

Affects of this change would allow Cypress to match version strings from Edge in both Microsoft Edge Beta 109.0.1518.49 and Microsoft Edge 109.0.1518.49 beta forms. This also applies to the Edge Canary and Edge Dev browsers.

Steps to test

How has the user experience changed?

PR Tasks

• Have tests been added/updated?
• Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• Has a PR for user-facing changes been opened in cypress-documentation?
• Have API changes been updated in the type definitions?

[CarbonCollins]

I've been looking into this one a little more and I'm not sure if the current format of these regex in the develop branch are even correct in the first place... I get this alternate format on both my linux machine and on a MacOS machine too.

Do we know if they worked prior to me raising this PR as I would like to determine if we need to still support the existing version string format?

[CarbonCollins]

To further follow up im seeing it in Microsoft Edge 110.0.1587.6 dev on my machine and Microsoft Edge 110.0.1587.6 Dev on the mac hence the case insensitivity addtion, however with the way that the code currently extracts the version from the regex the commit in this PR wont work...

[cypress]

2 failed and 43 flaky tests on run #43464 ↗︎

2

26598

1274

0

43

Details:

Merge branch 'develop' into add-alt-version-forms-for-edge-browser
Project: cypress	Commit: e127b8d995
Status: Failed	Duration: 19:25 💡
Started: Jan 26, 2023 8:25 AM	Ended: Jan 26, 2023 8:44 AM

  e2e/origin/commands/waiting.cy.ts • 1 failed test • 5x-driver-electron

View Output Video

Test
cy.origin waiting > alias > waits for the route alias to have a response

  migration.cy.ts • 1 failed test • launchpad-e2e

View Output Video

Test
global mode > migrates 2 projects in global mode		Screenshot

  e2e/origin/cookie_behavior.cy.ts • 4 flaky tests • 5x-driver-electron

View Output Video

Test
... > same site / cross origin > XMLHttpRequest > sets cookie on same-site request if withCredentials is true, and attaches to same-site request if withCredentials is true
... > same site / cross origin > fetch > sets same-site cookies if "include" credentials option is specified from request, but does not attach same-site cookies to request by default (same-origin)
... > same site / cross origin > XMLHttpRequest > sets cookie on same-site request if withCredentials is true, and attaches to same-site request if withCredentials is true
... > same site / cross origin > fetch > sets same-site cookies if "include" credentials option is specified from request, but does not attach same-site cookies to request by default (same-origin)

  cypress/cypress.cy.js • 3 flaky tests • 5x-driver-electron

View Output Video

Test
... > correctly returns currentRetry
... > correctly returns currentRetry
... > correctly returns currentRetry

  commands/net_stubbing.cy.ts • 1 flaky test • 5x-driver-firefox

View Output Video

Test
network stubbing > intercepting request > can delay and throttle a StaticResponse

  e2e/origin/commands/waiting.cy.ts • 1 flaky test • 5x-driver-firefox

View Output Video

Test
cy.origin waiting > alias > waits for the route alias to have a response

  cypress/cypress.cy.js • 3 flaky tests • 5x-driver-firefox

View Output Video

Test
... > correctly returns currentRetry
... > correctly returns currentRetry
... > correctly returns currentRetry

The first 5 flaky specs are shown, see all 21 specs in Cypress Cloud.

_{This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.}

[CarbonCollins]

Just to extend from my previous message at least, the updated regex should allow for both forms of the version string, the original Microsoft Edge Dev 110.0.0.0 and the one I'm seeing Microsoft Edge 110.0.0.0 Dev / Microsoft Edge 110.0.0.0 dev Without needing to change the way its decoded further down using a hardcoded capture group number...

I'm not sure if its the most appropriate way of doing this but the regex in the PR should return the version in either form as the 1st capture group regardless allowing the downstream code to remain unchanged.

[AtofStryker]

I'd like to get some unit tests in the future inside browsers_spec to validate Edge discovery seeing we don't have any, but I feel that's likely out of scope here.