-
Notifications
You must be signed in to change notification settings - Fork 73
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
Fix Fides.shouldShouldShowExperience() to return false for modal-only experiences #5281
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Skipped Deployment
|
…uld-show-experience
fides Run #9922
Run Properties:
|
Project |
fides
|
Branch Review |
refs/pull/5281/merge
|
Run status |
Passed #9922
|
Run duration | 00m 38s |
Commit |
6a797ccd74 ℹ️: Merge 2fb7e21c75c8762ef267e8e3d74df2d83d713474 into aa37211d487f7ec3a5b38b58f923...
|
Committer | Neville Samuell |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
0
|
Pending |
0
|
Skipped |
0
|
Passing |
4
|
Upgrade your plan to view test results. | |
View all changes introduced in this branch ↗︎ |
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.
Couple guiding comments!
// Never surface consent for modal-only experiences | ||
if (experience.experience_config?.component === ComponentType.MODAL) { | ||
return false; | ||
} |
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.
This is the fix - it's effectively a one-line adjustment to make this utility shouldResurfaceConsent()
behave as expected when using a modal-only experience. This method is called directly by Fides.shouldShowExperience()
to determine whether or not the experience will be shown to the user automatically during the init()
sequence.
(the rest of the PR is E2E tests for all the experience types)
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.
Great. Thanks for adding the e2e tests!
// If the given experience has no notices, return immediately and do not mutate | ||
// the experience object in any way | ||
if (!experience.privacy_notices) { | ||
return experience; | ||
} |
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.
This was an unrelated, but subtle bug. I found that if there was a saved consent cookie and a prefetched empty experience (e.g. experience: {}
), this function would get called and edit the experience to become { privacy_notices: undefined }
, which is unexpected by the rest of the code base.
The impact of this is probably zero-to-none, it'd be a really extreme edge case where a user (1) visits a website and gets a valid experience, (2) saves their consent preference, (3) visits the website again from a different location without an experience, (4) this method causes the experience to appear non-empty but without notices, (5) client will then refetch the experience client-side, slowing down the init.
Just fixing this up.
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. It's definitely not a common use case, but I can see how someone travelling or VPNing might get into this state.
{ | ||
fixture: "experience_modal.json", | ||
savedConsent: false, | ||
shouldShowExperience: false, | ||
}, |
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.
This was the failing case- without the fix to shouldResurfaceConsent
, this test fails because shouldShowExperience
returns true unexpectedly.
expiredTcfVersionHash, | ||
shouldShowExperience, | ||
}) => { | ||
describe(`when rendering ${fixture} and saved consent ${savedConsent ? "exists" : "does not exist"} ${expiredTcfVersionHash ? "(with expired tcf_version_hash)" : ""}`, () => { |
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 to the parameterized tests above, this'll exercise 9 different combinations of experiences + saved consent.
interface TestCaseOptions { | ||
fixture: | ||
| "experience_modal.json" | ||
| "experience_banner_modal.json" | ||
| "experience_tcf_minimal.json" | ||
| "experience_none.json"; | ||
savedConsent: boolean; | ||
expiredTcfVersionHash?: boolean; | ||
shouldShowExperience: boolean; | ||
} |
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.
This test fixtures modify three inputs:
fixture
: the type of experience to testsavedConsent
: whether or not the user has a previously saved consent cookieexpiredTcfVersionHash
: special case for TCF, whether the user should have a previously saved consent cookie but with an expired version hash (that doesn't match the latest experience)
It then asserts to see if Fides.shouldShowExperience()
returns the expected result of shouldShowExperience
in the param.
@@ -10,9 +10,6 @@ describe("Fides.showModal", () => { | |||
options: { | |||
isOverlayEnabled: true, | |||
}, | |||
experience: { |
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.
This was a red herring and didn't affect these tests, removing show_banner
entirely as it's not returned by the API anymore.
"auto_detect_language": true, | ||
"disabled": false, | ||
"id": "pri_exp-modal-000", | ||
"component": "modal", |
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.
Added this fixture to ensure we had a mock API response for the US-only modal component type.
@@ -0,0 +1,6 @@ | |||
{ | |||
"items": [], |
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.
Added this fixture to ensure we had a mock response for an empty experience, not matching any location.
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.
Tested through each use case and found the shouldShowExperience returned value to be correct each time. Found no issues with the code. Approved!
// Never surface consent for modal-only experiences | ||
if (experience.experience_config?.component === ComponentType.MODAL) { | ||
return false; | ||
} |
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.
Great. Thanks for adding the e2e tests!
// If the given experience has no notices, return immediately and do not mutate | ||
// the experience object in any way | ||
if (!experience.privacy_notices) { | ||
return experience; | ||
} |
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. It's definitely not a common use case, but I can see how someone travelling or VPNing might get into this state.
fides Run #9933
Run Properties:
|
Project |
fides
|
Branch Review |
main
|
Run status |
Passed #9933
|
Run duration | 00m 38s |
Commit |
47934f2610: Fix Fides.shouldShouldShowExperience() to return false for modal-only experience...
|
Committer | Neville Samuell |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
0
|
Pending |
0
|
Skipped |
0
|
Passing |
4
|
Upgrade your plan to view test results. | |
View all changes introduced in this branch ↗︎ |
Closes PROD-2763
Description Of Changes
This adds a tiny bit of logic to the FidesJS SDK function
shouldShowExperience()
to fix a bug where we would returntrue
confusingly for modal-only experiences that would not automatically show an experience to prompt for consent. The expected behaviour of this function is to returntrue
only when the user should be prompted via a consent banner.The bulk of this PR adds a thorough set of E2E tests to ensure that this SDK function is tested over all the FidesJS experience types, with & without saved consent.
Code Changes
shouldResurfaceConsent
helper to always return false for modal-only experiencesupdateExperienceFromCookieConsentNotices
to correctly handle prefetched experiences without any notices (e.g. an empty experience)show_banner
field that was removedSteps to Confirm
Fides.shouldShowExperience()
returnsfalse
as expectedFides.shouldShowExperience()
returnstrue
as expected and the banner is shownFides.shouldShowExperience()
returnsfalse
as expected and no banner is shownFides.shouldShowExperience()
returnstrue
as expected and the banner is shownFides.shouldShowExperience()
returnsfalse
as expected and no banner is shownPre-Merge Checklist
CHANGELOG.md
main
downgrade()
migration is correct and works