- Shipped
- 20 Agosti 2026, 05:37 UTC
- Author
- Kamo
- Commit
- 6236077
Diagnosed with Chrome over the debugging protocol rather than by reasoning, collecting exactly what Lighthouse's errors-in-console and inspector-issues audits collect: Runtime.consoleAPICalled, Runtime.exceptionThrown, Log.entryAdded, Network.loadingFailed and Audits.issueAdded. Four findings, all real, all now gone — verified against the built app before deploying rather than after. 1. A SCRIPT WAS BEING BLOCKED BY MY OWN CSP. Loading the script **************** violates ... violatedDirective: script-src-elem, blocked: csp `<link rel="preload" as="script">` is checked against script-src-elem, and under 'strict-dynamic' the browser ignores host allowlists — 'self' included. A preload also cannot inherit trust the way a script created by a trusted script does, because nothing created it: the nonce is the only thing that can allow it. The wrapper now stamps script preloads and modulepreloads too. This one block produced BOTH audit failures — the console error and the CSP issue — so it was most of the problem on its own. 2. **************** Chrome raises this when an input's `name` is itself an autocomplete token but no `autocomplete` attribute confirms it. The homepage signup field and two contact fields were doing that; declaring the attribute is also what the name was implying. 3. **************** six times on the contact form. Six labels, six controls, nothing connecting them — a real accessibility defect as much as an audit finding. Every control has an id and every label points at it. 4. A DocumentCookie performance issue from MrtBeacon. `document.cookie` is a synchronous blocking read and Chrome reports it; the beacon uses the async CookieStore where one exists and keeps the classic read for Firefox and Safari, which do not raise it. That made the cookie reads async, so both are resolved once up front and the scheduled send stays synchronous. check-mrt-cookie caught the restructure of (4) — it asserts `if (!visitorId) return;` exists verbatim, and I had folded it into a compound condition. The guard is right: that check is the entire basis for the beacon being ungated and should be hard to blur. The code matches it literally again. Chrome now reports 0 console errors, 0 exceptions, 0 network failures and 0 DevTools issues on both / and /contact.