Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: adding granular Firefox browser validation #23164

Merged
merged 16 commits into from
Aug 11, 2022

Conversation

tbiethman
Copy link
Contributor

@tbiethman tbiethman commented Aug 5, 2022

We recently ran into an issue where Cypress failed to connect to Firefox on Windows. A bug was identified within Firefox and a fix was released with v103, but v101 and v102 were not patched. Those versions will never work with Cypress on Windows.

I wanted to ensure we could communicate this incompatibility through the app, rather than have users run into this and have to be redirected to the closed issue. However, there wasn't a clean way of marking these specific version/architecture combinations as unsupported with our current logic. So I did a bit of refactoring to allow our default browsers objects to have an associated validator function that can more dynamically determine Cypress support.

User facing changelog

  • Stable Firefox versions 101 and 102 are now explicitly rendered as unsupported in Windows due to an unpatched browser incompatibility in those versions.

Additional details

Steps to test

We have pretty good test coverage around our minimum version checks. The new Firefox/Windows checks can be tested by installing 101 (or 102) and launching Cypress. You should see this:

Screen Shot 2022-08-03 at 5 00 33 PM

103 should render as normal.

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)
  • [n/a] Has a PR for user-facing changes been opened in cypress-documentation?
  • [n/a] Have API changes been updated in the type definitions?

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Aug 5, 2022

Thanks for taking the time to open a PR!


/** list of the browsers we can detect and use by default */

export const browsers: Browser[] = [
Copy link
Contributor Author

@tbiethman tbiethman Aug 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the additional logic in play here, it didn't feel right keeping the default browsers defined within the types package. It was a little weird to have them there in the first place? These were originally moved
with 5856776, but I don't see an impact to typings by moving these back.

This array was copied wholesale, with the firefox validator below being the only change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

}

return validateMinVersion(browser)
},
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not utilize the same validator for the dev/nightly channels as the impacts are much more undefined; some 100/101/102/103/104 versions will be impacted, some won't.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory we could use the info property to set more a of "ymmv" version of the message for those channels, but it is not actually rendering in the UI at the moment: #21769

This is early in my list to ask to prioritize after the search work is done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the heads up Mark, using info (when it works) would be perfect

}

return foundBrowser
browser.unsupportedVersion = true
browser.warning = warningMessage
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm noticing now that I abort early if isSupported is truthy; anyone see value 'it is supported but still has a warning' use case?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We sometimes use .warning for supported browsers, like with experimentalFirefoxSupport, there was a warning; data-context adds a warning too if chromeWebSecurity: false is used w/ Firefox... but I can't think of a use case that would apply at /this/ level of the browser detection so this seems fine.

@cypress
Copy link

cypress bot commented Aug 5, 2022



Test summary

37846 0 469 0Flakiness 4


Run details

Project cypress
Status Passed
Commit 9100208
Started Aug 11, 2022 2:31 PM
Ended Aug 11, 2022 2:51 PM
Duration 19:28 💡
OS Linux Debian - 11.3
Browser Multiple

View run in Cypress Dashboard ➡️


Flakiness

cypress/proxy-logging.cy.ts Flakiness
1 Proxy Logging > request logging > xhr log has response body/status code when xhr response is logged second
2 Proxy Logging > request logging > xhr log has response body/status code when xhr response is logged second
next.cy.ts Flakiness
1 Working with next-12.1.6 > should detect new spec
e2e/origin/commands/assertions.cy.ts Flakiness
1 cy.origin assertions > #consoleProps > .should() and .and()

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

@@ -110,7 +145,7 @@ describe('browser detection', () => {
info: 'Loaded from /foo/bar/browser',
custom: true,
version: '9001.1.2.3',
majorVersion: 9001,
majorVersion: '9001',
Copy link
Contributor Author

@tbiethman tbiethman Aug 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were previously setting the majorVersion as an integer if it could be parsed in setMajorVersion. But it's defined as a string on the FoundBrowser type and looks like it should to be (sometimes the version contains chars). So I normalized the type being set, and updated these tests.

@tbiethman tbiethman marked this pull request as ready for review August 8, 2022 15:19
@tbiethman tbiethman requested a review from a team as a code owner August 8, 2022 15:19
@tbiethman tbiethman changed the title chore: adding granular browser validation chore: adding granular Firefox browser validation Aug 8, 2022
@flotwig flotwig requested review from flotwig and ryanthemanuel and removed request for a team August 8, 2022 15:34
Copy link
Contributor

@flotwig flotwig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, tested that this blocks FF 101 on Windows and not on Linux, looks good.

Noticed a new defect though in the process 😄 #23200

packages/launcher/lib/browsers.ts Outdated Show resolved Hide resolved
Co-authored-by: Zach Bloomquist <git@chary.us>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>
Copy link
Collaborator

@ryanthemanuel ryanthemanuel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small comment. Tested this and it is working well. Nice work!

@tbiethman tbiethman merged commit 6d3b60a into develop Aug 11, 2022
@tbiethman tbiethman deleted the tbiethman/browser-validation branch August 11, 2022 14:51
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Aug 15, 2022

Released in 10.5.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v10.5.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Aug 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants