Environment
- LW Cookie 1.7.2
- Website: https://invescom.hu/
- GA4: installed via Google Site Kit
- Measurement ID:
G-R9MJ8CDK2E
- Google Consent Mode v2: enabled
- Tested in Chrome Incognito without ad blockers
Expected behavior
Before consent
analytics_storage = denied
- GA4 should be blocked
- No GA4 cookies should be created
- No GA4 tracking requests should be sent
After accepting analytics
analytics_storage = granted
- GA4 should be allowed to load
- GA4 tracking should start
_ga should be created
Actual behavior
The blocking before consent appears to work correctly.
However, after accepting all cookies:
- Consent is saved correctly
- Analytics consent becomes
true
- Google Consent Mode is updated
- GA4 still does not start
- No GA4
g/collect request is sent
- No
_ga cookie is created
The GA script appears to still be blocked by LW Cookie after consent has already been granted.
Suspected cause
After reviewing the plugin code, this looks like it could be a race condition between the Service Worker consent state and the page reload.
The Service Worker starts with an empty consent state:
and blocks requests if the relevant consent category is not available:
if ( ! consentState[category] ) {
event.respondWith(
new Response('', {
status: 403,
statusText: 'Blocked by LW Cookie'
})
);
}
When consent changes, the page sends the new state to the Service Worker:
navigator.serviceWorker.controller.postMessage({
type: 'consent-update',
consent: cats,
domains: DOMAINS
});
but the plugin also reloads the page shortly afterwards:
setTimeout(function () {
window.location.reload();
}, 100);
My suspicion is that the following can happen:
- User accepts analytics
- Consent is saved
- The Service Worker update is triggered
- Google Consent Mode changes to
granted
- The page reloads
- During the new page load, the Service Worker intercepts the GA request before it has the current consent state
- The analytics request is still treated as blocked
Possible solution
It may be safer to wait for an acknowledgment from the Service Worker before reloading the page.
For example:
page -> consent-update
service worker -> consent-updated
page -> reload
It may also help if the Service Worker can restore the persisted consent state immediately when it starts, instead of relying only on a new postMessage() from the page.
Google Consent Mode itself seems to be implemented correctly, so the issue appears to be related to the Service Worker hard-blocking logic after consent has already been granted.
The issue can currently be reproduced directly on:
https://invescom.hu/
Environment
G-R9MJ8CDK2EExpected behavior
Before consent
analytics_storage = deniedAfter accepting analytics
analytics_storage = granted_gashould be createdActual behavior
The blocking before consent appears to work correctly.
However, after accepting all cookies:
trueg/collectrequest is sent_gacookie is createdThe GA script appears to still be blocked by LW Cookie after consent has already been granted.
Suspected cause
After reviewing the plugin code, this looks like it could be a race condition between the Service Worker consent state and the page reload.
The Service Worker starts with an empty consent state:
and blocks requests if the relevant consent category is not available:
When consent changes, the page sends the new state to the Service Worker:
but the plugin also reloads the page shortly afterwards:
My suspicion is that the following can happen:
grantedPossible solution
It may be safer to wait for an acknowledgment from the Service Worker before reloading the page.
For example:
It may also help if the Service Worker can restore the persisted consent state immediately when it starts, instead of relying only on a new
postMessage()from the page.Google Consent Mode itself seems to be implemented correctly, so the issue appears to be related to the Service Worker hard-blocking logic after consent has already been granted.
The issue can currently be reproduced directly on:
https://invescom.hu/