This check detects a notification permission prompt triggered during initial page load or without a meaningful user gesture.
Why this matters
Unexpected prompts interrupt the visit before trust or intent exists. Browsers may quiet or block abusive prompting, and a premature denial can make it harder to request permission again later.
How to fix it
- Wait for an explicit action such as clicking “Enable alerts.”
- Explain what notifications will contain and how often they may arrive before invoking the browser prompt.
- Request only when notifications are necessary for the feature the user chose.
- Handle denied, granted, unsupported, and previously decided states without repeated prompting.
When the finding appears across many URLs, fix the shared component or layout that produces it instead of patching generated HTML page by page. Recheck representative templates and responsive states after deployment so the correction does not create a regression elsewhere.
How to verify the fix
Open the page in a fresh browser profile and confirm no permission UI appears on load. Trigger the feature deliberately and verify the native request follows the explanatory interaction.
Keep before-and-after evidence for the affected URL, original output, correction, and verification method. If markup changes after load, test consent states, localization, responsive variants, and client-side navigation because the initial HTML and rendered DOM can differ.