PH cookie gets set again after manually removing both the ph cookie and the cookiesjsr cookie and reloading the page (

Ok let's tackle this one next week together with the tests.

No I don't think so. We already spent a lot of time in this.

As the summary says, this is probably related to library itself. Let's keep this active, but not active active.

Still same problem, even after fixing 🐛 Only knock out if posthog_init is actually loaded Active .

@grevil: Please add a MR with a test for this.

Great stuff! This is now fixed through the recent changes! 🙂

I adjusted the existing tests to replicate this issue and also added a tiny test, to test the behavior of "consent_denied_persistence", since I didn't do that in the dedicated issue!

Please review!

This is great news indeed! Merged, thank you! I <3 tests :)

Automatically closed - issue fixed for 2 weeks with no activity.

Ok, unsure how relevant this is, but the original issue is NOT fixed.

The current behavior is, that when we consent, the posthog cookie appears as expected. If we then deny through the UI again or fire:

var options = { all: false };
document.dispatchEvent(new CustomEvent('cookiesjsrSetService', { detail: options }));

To deny, the posthog cookie disappears as expected (and as the newly added test replicates).

BUT if we simply remove the cookiesjsr cookie and the posthog cookie, and then reload, the original issue reappears and the posthog cookie gets set again. Only if we remove it again and then reload, it disappears.

How relevant is this @anybody? Should we eventually always set the cookiesjsr cookie on page load (With denied behavior as default) instead of only setting it, once we accept / deny?

Sounds like this might be a cookies issue. Maybe cookies doesn't handle missing (cookie) information like it was denied or something like that... no idea. Or it's a bug on the posthog side.

Anyway I'd rate this as minor edge-case, as the important user-facing functionality works and I have no clue how specific this might be.