-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Conversation
…tbiethman/browser-validation
Thanks for taking the time to open a PR!
|
|
||
/** list of the browsers we can detect and use by default */ | ||
|
||
export const browsers: Browser[] = [ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
} | ||
|
||
return validateMinVersion(browser) | ||
}, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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 |
@@ -110,7 +145,7 @@ describe('browser detection', () => { | |||
info: 'Loaded from /foo/bar/browser', | |||
custom: true, | |||
version: '9001.1.2.3', | |||
majorVersion: 9001, | |||
majorVersion: '9001', |
There was a problem hiding this comment.
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/browser-validation
There was a problem hiding this 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
Co-authored-by: Zach Bloomquist <git@chary.us>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>
There was a problem hiding this 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!
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
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 associatedvalidator
function that can more dynamically determine Cypress support.User facing changelog
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:
103 should render as normal.
How has the user experience changed?
PR Tasks
cypress-documentation
?type definitions
?