In Playwright, what happens to a window.confirm() dialog when no dialog handler is registered?

## The default nobody notices A JavaScript dialog -- `alert()`, `confirm()`, `prompt()` -- blocks the page until someone answers it. That is fatal for automation: one stray `alert()` on the issue detail page would freeze every action after it. Playwright removes the hazard by default. When **no** `dialog` listener is attached to the page, every dialog the page opens is dismissed automatically and immediately, and the action that triggered it completes as normal. Concretely: - `alert()` returns and execution continues. - `confirm()` evaluates to `false`, so the cancel branch runs. - `prompt()` returns `null`. - A `beforeunload` dialog is dismissed too, so navigation is not held up. This is why a test that clicks **Delete issue** on a page guarded by `confirm()` so often looks like it did nothing: the guard ran, the answer was cancel, and the issue is still on the board. The dialog was not ignored -- it was answered, just not the way the test author assumed. ## Registering a listener flips the contract Attach `page.on('dialog', ...)` and Playwright stops answering for you. It hands your callback a `Dialog` object and waits. If the callback never calls `dialog.accept()` or `dialog.dismiss()`, the dialog stays on screen, the page stays blocked, and the click that opened it never resolves -- the test fails on the action timeout with a message about the click, which is why this one is hard to diagnose from the error alone. The trap has three common shapes: an early `return` on some branch, a thrown assertion inside the callback that skips the answer, and a handler registered for a `confirm` that also receives an unexpected `alert` it has no branch for. Answer on every path. ## The Dialog object | member | what it gives you | | --- | --- | | `dialog.type()` | `alert`, `confirm`, `prompt` or `beforeunload` | | `dialog.message()` | the text shown to the user | | `dialog.defaultValue()` | a prompt's pre-filled value, empty otherwise | | `dialog.accept(promptText)` | answers OK, optionally supplying prompt text | | `dialog.dismiss()` | answers Cancel | | `dialog.page()` | the page that opened it | ## Ordering: listen first, act second 1. Register the handler -- `page.once('dialog', ...)` for a dialog you expect exactly one of. 2. Perform the action that opens it. 3. Await that action, then assert. The event fires *during* the click, not after it, so a handler registered on the line below the awaited click is registered too late. `page.once` is usually the right choice over `page.on` inside a test: it answers the dialog you are testing and then gets out of the way, instead of silently absorbing a second, unexpected dialog later in the same test. ## Assert, do not merely answer Answering a dialog proves nothing about the application. The interesting facts are that a dialog appeared at all, what it said, and whether the page honoured the answer. Capture `dialog.message()` into a variable inside the handler and assert on it after the action rather than asserting inside the callback -- an assertion that throws inside the handler leaves the dialog unanswered and turns a clear failure into a timeout. For a `prompt`, `dialog.accept('Cannot reproduce')` resolves it with that string while `dialog.dismiss()` makes it return `null`, so the two branches of the application's logic are both reachable from a test. ## Putting it together on an issue tracker Deleting an issue behind a confirmation is the canonical case. With no handler, the delete never happens and an assertion on the empty board fails for a reason the error message does not explain. With `page.once('dialog', d => d.accept())` registered before the click, the delete proceeds and the test is meaningful. With a handler that inspects but never answers, the click times out. All three outcomes come from the same page and the same click -- the difference is entirely in how the test set up its listener.