Consent module still active in Components bundle post Consent Pro split is breaking our main CMP function

Finsweet Components
1

Description

We’re seeing a consent conflict on our site caused by the Components app, and Webflow support helped us pin down the mechanism on your side. This behavior first appeared between 8/17 and 8/18 and has remained since.

**Root cause:** The Finsweet Components loader registered on our site builds its script URL at runtime and appends a cache-busting timestamp — pointing to a floating version rather than a pinned one. When you publish an update to the hosted bundle, our site picks it up automatically without any changes on our end. That’s why this surfaced suddenly (~8/18) with no corresponding change in our Designer, Assets, or page code — Webflow confirmed the script is injected by the App at publish time, not embedded/uploaded.

**The actual issue:** even though Cookie Consent has been migrated out of Components into Consent Pro (which we don’t have installed), the Components config bundle still includes a `consent` export and initializes it unconditionally — firing its own Google Consent Mode signal to dataLayer on every page load, competing with our primary CMP (Osano).

**What this looks like in practice:** a visitor opts in to all via our Osano banner on, the Finsweet module runs its own consent check — finds no Finsweet consent cookie of its own — and pushes a fresh Google Consent Mode update to dataLayer setting everything to denied, including functional storage. Since Google Consent Mode uses the most recent signal, this silently overwrites the state the user just granted through Osano, with no banner or visible UI on our end to explain why. This happens on the first page load and every subsequent one. Here is a quick video summary of the issue for your reference.

**What we need:** since we actively use Components for Marquee/Slider, uninstalling isn’t preferred but will go that route if needed. Please either:

  1. Confirm whether shipping consent logic in the Components bundle post-split is intentional, and if not, remove it from the hosted bundle going forward, or
  2. Give us a way to disable just the Cookie Consent module within Components (it currently shows “Migrated to new Consent Pro app” with no active config or toggle on our end).

Site URL

Steps to Reproduce

  1. Visit our site in a fresh/incognito session (no existing cookies).
  2. Accept cookies via the Osano banner.
  3. Open DevTools → Console, and run: dataLayer to inspect the array (or watch Network/Console in real time).
  4. Reload the page (or navigate to any other page on the site).
  5. Observe a second Consent Mode update pushed to dataLayer immediately after load, setting analytics_storage, functionality_storage, etc. back to denied — despite the user having just accepted via Osano.
  6. This repeats on every page load, every time, as long as the Finsweet Components script is present.

Expected Behavior

No interference from the Finsweet component code with consent, as we are not using any Finsweet consent apps on our site.

Actual Behavior

Our Osano consent state is overwritten on every page load when the Finsweet component script bundle doesn’t find any Finsweet consent cookies.

2

@sam2 — your diagnosis here is really thorough, and it’s exactly what we need to dig into this properly.

We’ve verified your setup from the HTML you shared:

  • You’re on Components v1.0.30 for Marquee/Slider ✓
  • You have zero fs-consent-* attributes anywhere on the site ✓
  • No Consent Pro product is implemented on your end ✓

So the pattern you’re seeing — consent signals firing from the Components bundle when Consent Pro isn’t configured — does look like unexpected behavior following the Cookie Consent → Consent Pro migration. Logically, separating consent into its own standalone product should mean the Components bundle wouldn’t be pushing Google Consent Mode signals for sites that never implemented it.

That said, we want to be straight with you: we can’t confirm from documentation alone whether this is a bug or an intentional architectural decision. That call has to come from our dev team who know the internals of the bundle.

Given what’s at stake here — active consent compliance impact on a live enterprise site with a third-party CMP — we’re escalating this immediately with your full technical context attached.

Our team will look at whether the consent export from the Components bundle should be gated or removed entirely for sites without Consent Pro, and we’ll come back to you with either a fix timeline or a confirmed workaround. :folded_hands:

3

Thank you, please keep me posted