Landing HR — cookie banner click-through fix (MC #106413, 2026-08-02) MC #106413 — cookie banner intercepts submit click (bilko.cloud) — fix Agent: codecraft Date: 2026-08-02 Worktree: /Users/makinja/business/ALAI-Holding-AS/products/bilko-wt-106413 Branch: fix/106413-cookie-banner (new worktree, NOT main checkout) Base: azdo/main @ e81db44a (2026-07-29) — git fetch azdo main fails in this environment ("could not read Username ... Device not configured", same failure documented in ~/system/evidence/106411/AUTHENTICATED-AZDO-MAIN-FETCH.txt and ~/system/evidence/103917-gap-closure/AUTHENTICATED-AZDO-MAIN-PROBE-2026-08-02.txt — not new). e81db44a is the tip multiple other in-flight worktrees (bilko-wt-106503, 106367-*, etc.) are already built from, so it's the best available local main. No push, no deploy. What was already known (not re-derived — read from MC #106413 + evidence/106405/fix-verdict.md §10) FlowForge (MC #106405) already root-caused this precisely, with a documented correction of their own first (wrong) hypothesis — see ~/.claude/projects/-Users-makinja/memory/feedback_plausible_story_is_not_diagnosis_2026-07-28.md . First hypothesis ("banner blocks Turnstile from loading") was measured and disproved: Turnstile is not consent-gated, loads and runs the challenge regardless of banner state. The real mechanism, measured with elementFromPoint at 1280x800: .cookie-banner is position: fixed; bottom: 0; z-index: 999 , occupying the bottom ~84px of the viewport (measured y 715.6–800). Submit button scrolled to viewport centre → hit = the button itself, not covered. Submit button scrolled to the end of the form (its natural resting position after a visitor reads through the form) → button rect y 754.6–799.6, entirely inside the banner strip → elementFromPoint returns .cookie-banner__text , not the button. The click goes to the banner, the submit handler never runs → zero feedback (no error, no spinner, no message). Dismissing the banner ("Samo nužni") removes the overlay and the same submit works immediately. Scope: bilko.cloud ( apps/landing-hr/index.html ) only. Confirmed by grep: class="cookie-banner" markup exists nowhere in apps/landing-ba/index.html or apps/landing-io/index.html — those two sites have no banner and no interception. Suggested fix in that evidence (not previously implemented, this ticket): give the page bottom padding equal to banner height while visible, OR make the banner non-blocking via pointer-events so only its own controls stay clickable. I implemented the second option. What was changed apps/landing-hr/index.html (the only file touched): .cookie-banner { position: fixed; left: 0; right: 0; bottom: 0; z-index: 999; background: var(--white); border-top: 1px solid var(--border); box-shadow: 0 -4px 24px rgba(35, 28, 51, 0.12); padding: 20px; display: none; + pointer-events: none; } ... .cookie-banner__text a { color: var(--plum); text-decoration: underline; + pointer-events: auto; } .cookie-banner__actions { display: flex; gap: 10px; flex-wrap: wrap; flex-shrink: 0; + pointer-events: auto; } (Full diff saved at time of work; see git diff on the worktree branch, lines ~1365–1415.) A comment was added above /* COOKIE CONSENT BANNER */ explaining the mechanism and why the fix takes this shape, for the next person who touches this file. Rationale for pointer-events over the bottom-padding alternative: the banner is shown/hidden purely via a JS class toggle ( is-visible ) with no fixed, known height (text can wrap to 2+ lines on narrow viewports — see the @media (max-width: 640px) rule), so reserving equivalent bottom padding would require JS to measure and re-apply the banner's live height on show/hide/resize. Making the banner's non-control surface click-transparent is simpler, has no JS dependency, and directly fixes the measured mechanism (the click landing on .cookie-banner__text ): a click on the plain notice text now passes through to whatever is actually underneath it, while the two buttons ( .cookie-banner__actions ) and the policy link ( .cookie-banner__text a ) explicitly opt back in with pointer-events: auto so the banner itself stays fully usable. This also fixes the broader consequence flagged in the evidence — the banner would have swallowed clicks on anything landing in that 84px strip, not just this one button. Checked for a click-outside-to-dismiss or other pointer-dependent behaviour on the banner container itself before making it pointer-events:none — the only two listeners are click on the accept/reject buttons ( apps/landing-hr/index.html:2694-2708 ), which are inside .cookie-banner__actions and remain fully interactive. No other pointer event is attached to .cookie-banner / .cookie-banner__inner / .cookie-banner__text directly. Verification Existing landing test suite, full run, before touching anything: npm run test:landing equivalent ( node --test tests/landing/*.test.mjs ) — 29 pre-existing tests, all pass (lead-kv ×2 markets + conversion_event + turnstile-sitekey). New regression test added: tests/landing/cookie-banner-click-through.test.mjs — 6 cases, static assertions against the