MarketSquare / MarketSquare/robotframework-browser

Add `expected_type=` to `Wait For Alert` and `types=` to `Wait For Alerts` to verify the dialog type

Open
#5,118 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Python
Stars
655
Forks
147
Avg merge
5h 27m
Merged PRs (30d)
59

Description

Use case

Wait For Alert and Wait For Alerts can already verify a dialog's text, but they cannot verify which kind of dialog fired. A page can show either a confirm() or a prompt() depending on state, and a regression that swaps one for the other (or that suddenly shows a plain alert() instead of a confirmation) currently passes silently as long as the text happens to match — and if the texts are identical or empty, there is no way at all to tell the dialogs apart. Playwright knows the type of every dialog (alert, confirm, prompt, beforeunload), but the library never surfaces it, and there is no workaround because dialogs cannot be inspected by any other keyword.

Asserting the type alongside the text is a natural extension of the same keyword that already returns the message text.

Proposed keyword / arguments

New named-only argument on Wait For Alert:

  • expected_type: DialogType | None = None — one of alert, confirm, prompt, beforeunload. When given, the keyword fails if the handled dialog's type differs. Default None skips the check (current behavior).

Matching new argument on Wait For Alerts:

  • types: list[DialogType | None] | None = None — one entry per expected dialog, None entries skip the check for that dialog. Default None disables type checking entirely (current behavior). When given, the list length must match actions/prompt_inputs/texts, consistent with the existing validation.
${promise} =    Promise To    Wait For Alert    action=accept    text=Delete this item?    expected_type=confirm
Click           id=delete
${text} =       Wait For    ${promise}

# Two dialogs: first must be a confirm, second a prompt
${promise} =    Promise To    Wait For Alerts
...    ["accept", "accept"]
...    [None, "my input"]
...    [None, None]
...    types=["confirm", "prompt"]
Click       id=confirmAndPrompt
${texts} =    Wait For    ${promise}

Playwright API

Maps to dialog.type(), which returns one of alert, beforeunload, confirm or prompt. The dialog object is already handled inside the wrapper's waitForAlerts implementation; its type just needs to be read and checked.

Implementation notes

  • protobuf/playwright.proto: extend the AlertAction message with an optional expected type field.
  • node/playwright-wrapper: in the dialog handler, compare dialog.type() against the expected type (when set) and reject with a clear error message on mismatch.
  • Browser/keywords/interaction.py: add expected_type to wait_for_alert and types to wait_for_alerts (with the same length validation as the existing lists), plus a DialogType enum in Browser/utils/data_types.py if none fits.
  • Docs and atest: the test app already triggers alert/confirm/prompt dialogs.

Backwards compatibility

Purely additive: both arguments default to None, which skips type verification entirely, so all existing suites behave exactly as before.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with protobuf/playwright.proto, Browser/keywords/interaction.py, Browser/utils/data_types.py, and the node/playwright-wrapper dialog handler. Trace the existing alert and alerts argument validation and dialog handling, then use the atest application to verify type matching, skipped checks, list-length validation, and unchanged defaults.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, playwright, python
Domain
testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
70/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.