[mattpmerrill]

The sessions never set unhandledPromptBehavior, so the default "dismiss and notify" applied and every alert, confirm and prompt was closed as soon as it opened. confirm() always returned false and prompt() always returned null.

All three session paths (launch, --connect-existing and Android) now request unhandledPromptBehavior "ignore". Marionette sends NoSuchAlertError with an empty message, so accept_dialog and dismiss_dialog now check error.name and report "No active dialog" again.

How other tools behave while a dialog is open:

• new_page, navigate_history and set_viewport_size use WebDriver Classic and fail with Unexpected confirm dialog detected. Performed handler "ignore" until the dialog is handled.
• take_snapshot, screenshot_page and list_pages keep working.
• navigate_page unloads the page, which closes the dialog.
• A click_by_uid whose click handler opens a dialog now waits for the 10s BiDi timeout and fails with "BiDi command timeout: input.performActions", although the dialog is open and accept_dialog works right after. evaluate_script calling confirm() directly times out after 5s the same way. Before this change the click returned at once, since the dialog was already closed. Bug 2081600 would let these tools report the open dialog instead.

Testing:

• New tests/integration/dialog.integration.test.ts covers accept and dismiss for confirm and prompt, and the no-dialog error. 4 of the 5 tests fail without the core.ts change.
• With --connect-existing against a running Firefox, the session reports unhandledPromptBehavior "ignore". Android is covered by a unit test only, I could not test on a device.

[juliandescottes]

I tested a bit the PR, and I think before we can merge it we need to address the blocker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=2080970, which will migrate the tools to handle dialogs to BiDi. Otherwise, it will put the mcp in a hard to use state when dialogs start appearing, especially if they are not in the current tab.

We also have Bug 2081600 - [firefox-devtools-mcp] Report open alert/confirm/prompt dialogs and the tools that handle them which is potentially a blocker here. At the moment the MCP is not great at exposing the state of the browser after a tool was called. So imagine you trigger some user input, which leads to showing a prompt: at the moment the agent will have no way to know about this and only the user can unblock the situation.

Finally, this is a bit tricky to enable until we have migrated most of the tools outside of webdriver classic (because classic commands throw if a dialog is opened - although that would be less of an issue if Bug 2081600 is handled first).

So my advice here would be table that, at least until Bug 2080970 is fixed. Would you be interested in picking this other bug up ?

[hbenl]

@mattpmerrill Thanks for the PR, I have included the fix in #234.