How QA.tech handles browser dialogs (alerts, confirms, prompts) during automated testing
window.alert()
- Simple notification dialogs with just an “OK” button.
Handled by default: ✅ Yes - automatically accepted and text capturedwindow.confirm()
- Dialogs with “OK” and “Cancel” options. Handled by
default: ❌ No - can be enabled on requestwindow.prompt()
- Dialogs that request text input from the user.
Handled by default: ❌ No - can be enabled on requestwindow.onbeforeunload
- Dialogs shown when leaving a page with unsaved
changes. Handled by default: ❌ No - can be enabled on requestalert()
, confirm()
, and prompt()
dialogs in modern web
applications.alert()
, confirm()
, prompt()
) are legacy APIs with significant limitations:
Custom Modal Components
Inline Validation & Messaging
Toast & Snackbar Notifications
Dedicated Confirmation Flows
alert
, confirm
, prompt
in your codebase 2. Prioritize - Start with
high-traffic, user-facing areas first 3. Build - Develop reusable modal
and notification components 4. Replace - Swap native dialogs
incrementally, verifying behavior 5. Test - Ensure custom components work
with your automated testsalert()
only for debugging/development - never in production -
Replace all browser dialogs with custom modals in production applications -
Describe dialog expectations clearly in your test goals (e.g., “expect a
success confirmation after form submission”)alert()
, confirm()
, prompt()
) for
production user interfaces - Use dialogs for complex user interactions -
Expect dialogs to work consistently across all devices and browsers