User prompts

A page’s alert, confirm and prompt stop the page until they are answered, and a page script cannot keep them open for a client to answer later. So the plugin replaces them in the page (and in same-origin frames) with versions that answer at once and record the dialog. Paths follow http://127.0.0.1:4445/{token}; see the overview for the reply format and the errors.

On macOS a real app answered a confirm and a prompt (with the answer set before, and with the default dismiss), refused accepting a confirm that had been dismissed when it opened, saw an alert leave the answer to the confirm after it, and cleared the two in order.

How dialogs are answered#

The plugin replaces the dialogs whenever it is on (in debug builds by default), also while no test drives the app: the app’s dialogs then never show, and answer as below. A same-origin frame gets the replacements when the next command runs after the frame has loaded; a dialog it opens before that is the real one.

• A confirm or prompt gets the answer the client set before it opened: POST /alert/accept or POST /alert/dismiss with no dialog recorded (the last one sent counts), and for a prompt POST /alert/text first for the text it returns. The first confirm or prompt uses that answer up; an alert needs none and leaves it for the next one. With no answer set, a confirm or prompt is dismissed (false, null), as W3C’s default dismiss would. A prompt accepted with no text set returns its default value (the second argument of prompt), or the empty string.
• Every dialog is recorded, oldest first (the last 100 are kept), and GET /alert/text reads the oldest one’s message, or no such alert.
• Accept or dismiss after a dialog opened clears the oldest record when it is the answer the page got (either one for an alert). The other one answers unsupported operation and keeps the record: the page already has its answer and cannot be given another. Sending text to a prompt that has opened answers unsupported operation, and to an alert or confirm element not interactable.
• While a dialog is recorded, accept or dismiss handles it and sets no answer. So clear the dialogs a test does not care about (or check GET /alert/text) before setting the answer for the next one. An answer that no dialog used stays set for the next confirm or prompt, however much later; POST /alert/dismiss with no dialog recorded puts the default back.
• Commands never fail with unexpected alert open. The dialogs and the answer are forgotten when the page loads another document and when a new session starts.

So a test that should accept a confirm accepts first, then clicks:

sb.accept_alert().await?;                 // the answer for the next confirmsb.click("#delete").await?;               // confirm(...) returns true at onceassert_eq!(sb.get_alert_text().await?, "Delete the profile?");sb.accept_alert().await?;                 // clears the record

Get alert text#

GET /session/{sessionId}/alert/text

Errors

Accept alert#

POST /session/{sessionId}/alert/accept

With a dialog recorded: clears the oldest one, if it was accepted when it opened (any alert was). With none: sets accept as the answer for the next confirm or prompt, with the text sent before it, if any.

Errors

Dismiss alert#

POST /session/{sessionId}/alert/dismiss

With a dialog recorded: clears the oldest one, if it was dismissed when it opened (any alert can be). With none: sets dismiss as the answer for the next confirm or prompt, which puts the default back.

Errors

Send alert text#

POST /session/{sessionId}/alert/text

With no dialog recorded: keeps the text for the answer that the next POST /alert/accept (or dismiss) sets, so the next prompt accepted returns it.

Errors