Fix cookieconsent2 false-positive blocking didomi opt-out on Evite#1323
Merged
Fix cookieconsent2 false-positive blocking didomi opt-out on Evite#1323
Conversation
The cookieconsent2 rule used { "visible": "#cm" } to detect an open
popup, but the autoconsent visibility check treats fixed-position
elements as visible regardless of their CSS visibility property. On
Evite (and likely other sites) the orestbida/cookieconsent v2 modal
is initialized with style="visibility: hidden" and position:fixed
yet remains in the DOM even when no consent banner is being shown.
This caused the cookieconsent2 rule to falsely match and either
short-circuit detection of the real didomi popup or fail because
#s-rall-bn doesn't exist.
Switch to detecting the canonical "show--consent" class that
cookieconsent v2 (>=2.1) toggles on the html element when the modal
is actually open. This matches the library's own visibility logic
and avoids the visibility:hidden false-positive.
Co-authored-by: Maxim Tsoy <maks.tsoy@gmail.com>
|
Cursor Agent can help with this pull request. Just |
Collaborator
|
CI run finished. Artifacts ZIP for the review tool |
Collaborator
|
CI run finished. Artifacts ZIP for the review tool |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Task/Issue URL: https://app.asana.com/1/137249556945/project/1203268166580279/task/1214074223746047?focus=true
Description:
Fixes popup handling on
evite.comevent pages (and similar sites) where the cookie banner was not being dismissed.Root cause
Evite ships the
orestbida/cookieconsentv2 library globally and leaves its modal (#cc--main/#cm) in the DOM even when no banner is being shown. The modal element hasstyle="visibility: hidden"andposition: fixed, but autoconsent's internalisElementVisiblehelper treats any fixed-position element withdisplay !== 'none'as visible —visibility: hiddenis ignored. Combined with the previouscookieconsent2rule'sdetectPopup: { "visible": "#cm" }step, the rule was matching on Evite even though no banner was open.In US/CA regions this caused the rule to "win" the popup-detection race ahead of the real
didomibanner and then fail at opt-out (#s-rall-bndoesn't exist). In FR it produced aFound multiple CMPswarning while didomi happened to also fire. In DE/GB the timing worked out so didomi handled it, but the falsecookieconsent2detection was still happening.Fix
Detect the
cookieconsent2popup viahtml.show--consent #cm. The orestbida/cookieconsent v2 library (since v2.1) toggles theshow--consentclass on the<html>element to actually show the modal (CSS in the library appliesvisibility: visible !importantbased on this class). Usingexistsrather thanvisibleavoids the fixed-position visibility quirk, and the class is the canonical signal that the banner is actually open.The existing
{ "exists": "#s-all-bn" }step is preserved so the rule still confirms the accept button is mounted before attempting to interact.Verification
Tested via BrightData remote browsers across geographic regions.
Before the fix:
de/gb:didomiopt-out worked butcookieconsent2was incorrectly co-detectedfr:Found multiple CMPswarning (cookieconsent2+didomi)us-losangeles/ca:cookieconsent2won the popup race →optOutResult: false(no#s-rall-bn), didomi never triedAfter the fix:
de/gb/nl/us-newyork/us-losangeles/fr: onlydidomidetected,optOut: true, popup dismissed (no more multi-CMP warning)ca: onlydidomidetected; popup handling now occasionally flaky because the didomi notice on Evite-CA appears at ~6s while autoconsent'swaitForPopupretries for ~5s — this is a pre-existing engine timing issue independent of this rule fix, previously masked by the cookieconsent2 false-positive.Smoke-tested the rule still works on real cookieconsent v2 sites (
fashionnetwork.com,officeshoes.ro):optOut: true,autoconsentDone.npm run build-rules,npm run rule-syntax-check, andnpm run lintall pass.Evite event page after autoconsent opt-out (FR region, popup gone):
Evite FR after fix
Evite DE after opt-out (didomi flow, full page rendered):
Evite DE after opt-out
Reference: didomi popup that needs to be opted out (CA region, no autoconsent):
Didomi popup on Evite CA
Steps to test this PR:
npm run prepublishdist/addon-mv3/as an unpacked extension in ChromeFound CMP: didomiandoptOutResult: true(only one CMP, noFound multiple CMPswarning)cookieconsent2is co-detectedfashionnetwork.com) that the rule still detects, opts out, and dismisses the bannerTo show artifacts inline, enable in settings.