In Selenium, which commands still work while a JavaScript alert is open, and which fail?

## What "the page is blocked" means at the wire level When a page calls `alert`, `confirm` or `prompt`, the call does not return until a button is pressed: the calling script is suspended and the browser will not run the page's other work. The **driver** is blocked too, but for a different reason — the WebDriver protocol builds it in. Almost every command's remote-end steps begin with a **handle any user prompts** step, which looks for an open **user prompt** before the command does anything else. When one is open, the session's prompt handler runs; under Selenium 4's default of `dismiss and notify` the prompt is dismissed and the command then fails with `unexpected alert open`, surfaced by the Java client as `UnhandledAlertException`. So commands do not queue up behind the dialog, and they do not time out. They reach the remote end, get intercepted at their first step, and come straight back as an error. ## What still gets through Exactly one family of commands is exempt: the four that exist to answer the prompt. | Call (Java) | Runs handle-any-user-prompts? | Behaviour while a dialog is open | |---|---|---| | `switchTo().alert().getText()` | No | Returns the dialog's message | | `switchTo().alert().accept()` | No | Presses OK and closes the dialog | | `switchTo().alert().dismiss()` | No | Presses Cancel and closes the dialog | | `switchTo().alert().sendKeys(text)` | No | Types into a `prompt`'s input field | | `findElement(By.id("order-number"))` | Yes | Handler applies; `UnhandledAlertException` by default | | `findElement(...).click()` | Yes | Same, before the click is attempted | | `getCurrentUrl()`, `getPageSource()` | Yes | Same, before anything is read | | `executeScript(...)` | Yes | Same; the script never runs | The exemption is not a special case bolted on afterwards. Without it no command could reach the dialog, and any prompt a page opened would be unanswerable. It is also why the shape of a dialog-handling test is so rigid: the action that raises the prompt, then the alert commands, then everything else. Any ordinary call slipped between the trigger and the answer meets the handler first and turns a working flow into a failure. ## The opposite failure: `NoAlertPresentException` Calling `driver.switchTo().alert()` when no dialog is open throws **`NoAlertPresentException`**, the Java form of the W3C `no such alert` error. It does not return `null`, it does not block, and a configured implicit wait does not make it retry, because implicit waiting governs element location rather than prompts. Two situations produce it on a bookshop checkout: 1. **Too early.** The click on **Place order** returned, but the page has not raised its `confirm` yet, so the switch runs against nothing. 2. **Too late.** Something already answered the dialog — a session prompt handler of `accept` or `dismiss`, or an earlier line in the same test — so no prompt is left by the time the switch runs. Both are statements about the test's timing, not proof that the application never opened a dialog. Reading `NoAlertPresentException` as "the confirmation step is broken" is a common misdiagnosis. ## The alert switch is not a context switch `switchTo()` is shared with the frame and window targets, which makes `alert()` look like another move. It is not one. Taking an `Alert` handle leaves the driver's current frame and current window exactly as they were, and after `accept()` the very next `findElement` searches the same context it would have searched had no dialog ever appeared. There is nothing to switch back from. ## Reading a failing checkout run 1. The run fails on an ordinary call such as `findElement`, not on anything dialog-shaped. 2. The exception is `UnhandledAlertException`, and its `getAlertText()` names the message that blocked it. 3. Manual reproduction shows no dialog, because the default handler dismissed the one that caused the failure. 4. The trigger is the action on the previous line; the failing command was only the first one to notice. ## Practical consequences - A native dialog cannot be asserted on with page-content calls, since those calls are gated before they read anything. - A dialog left unanswered by one test fails the **next** test when the session is reused, on that test's first command. - Under the `ignore` handler the dialog stays open, so every following command fails identically until the test answers it. - `executeScript` is not an escape hatch: it is gated like everything else, so no script can be injected to click the dialog away. - A checkout that raises a `confirm` only for some baskets makes the failure look intermittent, when the dialog is deterministic and the basket is what varies.