Loading challenge...
Unsaved-Changes Guard
Arm a beforeunload handler on a dirty form and handle the native leave-confirmation in automation
What you will learn
- Understand how the beforeunload event guards against losing unsaved work and why preventDefault() + returnValue are both required
- Register a dialog handler before navigation so automation deterministically accepts or dismisses the native leave-confirmation
- Drive a dirty/clean state machine via DOM attributes (data-dirty) rather than racing the browser's native dialog
Unsaved-Changes Guard
Editing the field arms a beforeunload handler that fires the browser's native 'leave site?' confirm — saving disarms it
Type into the field below and it becomes dirty: a beforeunload listener is registered that calls preventDefault() and sets returnValue, so closing the tab or navigating away pops the browser's native confirmation. Clicking Save marks the work persisted and removes the listener — a clean field leaves silently.
Current state: clean (safe to leave)
Edit, Save, or Leave
Make the field dirty, then try to navigate away
Testing Tips
Automation hints
- ✓ Playwright auto-accepts a
beforeunloaddialog unless you registerpage.on('dialog', …)before navigating — without it the prompt is dismissed silently and your test leaks the unsaved state instead of asserting it - ✓ Cover three cases: clean-leave (no edit → navigate, expect no dialog), edit-stay (type into
#guarded-input, dismiss the prompt, stay), and edit-leave (type, accept the prompt, navigate via#leave-link) - ✓ Don't poll the native dialog — assert the armed flag on
#guard-state[data-dirty="true"]after filling, anddata-dirty="false"after clicking#save-button - ✓
#save-buttonis disabled while clean — fill#guarded-inputfirst; saving clears the guard without erasing the text, so a re-edit re-arms it
