TRAC-1395: fix - treat consent as granted when the store has cookie consent disabled by parthshahp · Pull Request #3163 · bigcommerce/catalyst

parthshahp · 2026-08-04T17:21:11Z

What/Why?

When cookieConsentEnabled (setting in the control panel) is off, c15t grants every consent category client-side but only in its in-memory store, so no c15t-consent cookie is ever written. hasConsentFor read the cookie as the sole source of truth and so returned false for every category on those stores.

hasConsentFor now falls back to the store's cookie consent setting when no consent cookie is present. An explicit consent cookie still takes precedence.

Also seeds an explicit functionality-consent cookie in the two alternate currency e2e tests so they assert the consented path rather than depending on the test store's cookieConsentEnabled setting, and moves the consent cookie builder duplicated in analytics-session.spec.ts into a shared test helper.

Testing

Tested using local tests as well as CI.

Before, you can see that I must refresh for the currency to take effect:

Screen.Recording.2026-08-05.at.5.06.47.PM.mov

After:

Screen.Recording.2026-08-05.at.3.47.55.PM.mov

Migration

No migration needed.

vercel · 2026-08-04T17:21:18Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
catalyst	Ready	Preview	Aug 19, 2026 6:39pm

changeset-bot · 2026-08-04T17:21:18Z

🦋 Changeset detected

Latest commit: 8c58638

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@bigcommerce/catalyst-core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

github-actions · 2026-08-04T17:22:30Z

Bundle Size Report

Comparing against baseline from 06775b2 (2026-08-19).

No bundle size changes detected.

parthshahp · 2026-08-04T17:39:47Z

+  currency,
+}) => {
  const format = getFormatter();
+


This is the actual e2e test fix: we can just set the cookie explicitly for the test that we need

github-actions · 2026-08-04T18:04:05Z

Unlighthouse Performance Comparison — Vercel

Comparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores.

Summary Score

Aggregate score across all categories as reported by Unlighthouse.

	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
Score	90	93	91	95

Category Scores

Category	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
Performance	77	89	69	76
Accessibility	95	95	95	98
Best Practices	100	100	100	100
SEO	88	88	88	100

Core Web Vitals

Metric	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
LCP	3.6 s	3.7 s	4.2 s	6.6 s
CLS	0	0	0.037	0.011
FCP	1.2 s	1.2 s	1.2 s	1.2 s
TBT	0 ms	10 ms	10 ms	0 ms
Max Potential FID	40 ms	80 ms	60 ms	40 ms
Time to Interactive	3.7 s	3.7 s	6.5 s	6.6 s

Full Unlighthouse report →

parthshahp · 2026-08-04T18:47:39Z

+      return;
+    }
+
+    saveConsents('all');


If cookie consent is disabled in the control panel, act like the user "accepts all".

On second thought; this might not be such a good idea: https://c15t.com/docs/shared/react/hooks/use-consent-manager/setting-consent

From the documentation, it looks like saveConsents stores the value in localstorage. If a merchant decides to later enable cookie consent, this "fake consent" may still be stored in localstorage for the user.

(Edit: this is a rare case we needn't account for)

Are we planning to do something about this?

Nope, we probably don't really need to account for this. The consent cookie has expiration anyway

parthshahp · 2026-08-04T19:22:37Z

This is what I came up with to resolve the issue of:

Consent cookies are disabled.

Shopper goes to site and consent is granted for all scope.

Consent cookies are enabled.

Shopper goes to site, but does not see banner because consent is granted for all scope still.

I'm not sure if this is a real scenario that we should consider or not.

Another solution here would be to just call isCookieConsentEnabled on the set currency code server action. We can also cache this request, and we need to remember to call it for any server action that may also depend on consent cookies (like analytics).

Thinking more about it I don't really like this localstorage solution, and we should just bite the bullet and make sure to check the consent cookie setting on relevant server actions, but I'll leave this up unchanged to get feedback first.

I don't think that is a scenario we really need to worry about. Definitely an edge-case, because once a merchant enables it, the consent cookies will expire and will require consent after some time.

We store cookie consent both in localstorage and in cookies. You'll need to dive into what c15t does, but we made sure we designed it that way to integrate better with Next.js.

Edit: technically, this method is not GDPR or CCPA compliant but we document this here: https://docs.bigcommerce.com/developer/docs/storefront/catalyst/features/cookie-consent

Ok, so then should I just go with

the saveConsents('all'); approach (if cookie consent is enabled)

make a request on server action specifically for set currency code?

make a request on server action specifically for set currency code?

What is this for?

The specific issue regarding currency code is this:

On the set currency code server action, we check the consent cookie.

Before this PR, we weren't saving a consent cookie even when the consent cookies were disabled, meaning that the currency code wasn't able to be changed.

catalyst/core/lib/currency.ts

Line 25 in 7848623

if (!(await hasConsentFor('functionality'))) {

The current PR's solution to this is to just set the cookie with 'all' scopes when we see that consent cookies are disabled in the control panel.

The alternative I was suggesting to my above solution is: we make an extra request inside of the set currency code server action to check the consent cookies control panel setting on our own (create a new graphql request). If it is set to false, we don't care about the consent cookie.

The issue with the alternative is that it doesn't fix the analytics case (doesn't start visit + deletes visits).

catalyst/core/proxies/with-analytics-cookies.ts

Line 21 in 7848623

if (!(await hasConsentFor('measurement'))) {

chanceaclark · 2026-08-04T21:10:13Z

+      return;
+    }
+
+    saveConsents('all');


Heads up that StartVisitOnConsent won't call startVisit for this path. c15t grants synchronously when enabled: false, so wasMeasurementGranted over there initializes to true — there's no false → true transition to observe. The analytics recovery for first-load is deferred to the second request once this cookie is readable. I think that's fine, mind adding a note to the comment above so it's not mysterious later?

Sure, updated the comment!

Well... no it actually shouldn't be a comment. We need to actually make sure it fires whenever cookie consent is turned off.

Answered with this change: #3163 (comment)

parthshahp · 2026-08-05T21:30:25Z

+  const hasStartedVisit = useRef<boolean | null>(null);
+
+  if (hasStartedVisit.current === null) {
+    hasStartedVisit.current = getConsentCookie()?.['c.measurement'] ?? false;


hasStartedVisit depends on if the cookie exists. We've removed the wasMeasurementGranted ref since that only starts the visit on a false -> true change.

mfaris9 · 2026-08-17T23:21:27Z

LGTM, but should we run this by legal for this scenario? It might be overkill, but I would hate to cause a GDPR issue:

Day 1: consent disabled -> shopper visits, cookie says "accepted everything"
Day 2: merchant enables consent in the control panel
Day 3: same shopper returns -> cookie already says "accepted", so
no banner shows and they're tracked as if they opted in

parthshahp · 2026-08-18T13:56:01Z

There's already a comment for this in the PR. TLDR this is an edge case and we have an expiration on the cookie anyway

…sabled c15t grants every consent category when `cookieConsentEnabled` is off, but only inside its in-memory store — it never persists them. `hasConsentFor` reads the consent cookie, so it saw nothing and treated the shopper as having declined, silently dropping the selected currency and preventing the analytics visitor/visit cookies from ever being set. The consent manager now persists that automatic grant, so the consent cookie stays the single source of truth on both sides and `hasConsentFor` needs no store lookup — no added work in the proxy, and no added fetches anywhere, since c15t runs in offline mode and persisting is storage-only. Known tradeoff: this records a grant the shopper was never asked for. If a store later enables cookie consent, returning shoppers carrying that cookie get `showPopup: false` and won't see the banner. Marking the grant and resetting it on that transition was considered and rejected as more machinery than the case warrants. Also seeds an explicit functionality-consent cookie in the two alternate currency e2e tests so they don't race the client-side grant or depend on the test store's `cookieConsentEnabled` setting, and moves the consent cookie builder duplicated in analytics-session.spec.ts into a shared test helper.

parthshahp commented Aug 4, 2026

View reviewed changes

Comment thread core/lib/consent-manager/has-consent-for.ts Outdated

parthshahp commented Aug 4, 2026

View reviewed changes

parthshahp force-pushed the trac-1395 branch from 7d9a58e to b5ba0b6 Compare August 4, 2026 18:45

vercel Bot deployed to Preview August 4, 2026 18:46 View deployment

parthshahp commented Aug 4, 2026

View reviewed changes

parthshahp force-pushed the trac-1395 branch from b5ba0b6 to 57ececf Compare August 4, 2026 19:12

vercel Bot deployed to Preview August 4, 2026 19:13 View deployment

parthshahp force-pushed the trac-1395 branch from 57ececf to cc31fb7 Compare August 4, 2026 19:17

vercel Bot deployed to Preview August 4, 2026 19:18 View deployment

parthshahp commented Aug 4, 2026

View reviewed changes

parthshahp force-pushed the trac-1395 branch from cc31fb7 to f1f219d Compare August 4, 2026 19:43

vercel Bot deployed to Preview August 4, 2026 19:44 View deployment

parthshahp force-pushed the trac-1395 branch from f1f219d to 78d2a63 Compare August 4, 2026 19:51

parthshahp marked this pull request as ready for review August 4, 2026 19:51

parthshahp requested a review from a team as a code owner August 4, 2026 19:51

vercel Bot deployed to Preview August 4, 2026 19:52 View deployment

chanceaclark reviewed Aug 4, 2026

View reviewed changes

parthshahp force-pushed the trac-1395 branch from 78d2a63 to 2228df9 Compare August 5, 2026 15:21

vercel Bot deployed to Preview August 5, 2026 15:22 View deployment

parthshahp force-pushed the trac-1395 branch from 2228df9 to 26d0dce Compare August 5, 2026 19:45

vercel Bot deployed to Preview August 5, 2026 19:46 View deployment

parthshahp commented Aug 5, 2026

View reviewed changes

parthshahp force-pushed the trac-1395 branch from 26d0dce to a4a78b7 Compare August 5, 2026 21:33

vercel Bot deployed to Preview August 5, 2026 21:34 View deployment

parthshahp force-pushed the trac-1395 branch from a4a78b7 to 8c58638 Compare August 19, 2026 18:38

vercel Bot deployed to Preview August 19, 2026 18:39 View deployment

Uh oh!

Conversation

parthshahp commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What/Why?

Testing

Migration

Uh oh!

vercel Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

changeset-bot Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

github-actions Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Bundle Size Report

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Unlighthouse Performance Comparison — Vercel

Summary Score

Category Scores

Core Web Vitals

Uh oh!

Choose a reason for hiding this comment

Uh oh!

parthshahp Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chanceaclark Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chanceaclark Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mfaris9 commented Aug 17, 2026

Uh oh!

parthshahp commented Aug 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

parthshahp commented Aug 4, 2026 •

edited

Loading

vercel Bot commented Aug 4, 2026 •

edited

Loading

changeset-bot Bot commented Aug 4, 2026 •

edited

Loading

github-actions Bot commented Aug 4, 2026 •

edited

Loading

github-actions Bot commented Aug 4, 2026 •

edited

Loading

parthshahp Aug 4, 2026 •

edited

Loading

chanceaclark Aug 4, 2026 •

edited

Loading

chanceaclark Aug 5, 2026 •

edited

Loading