browser_handle_dialog
Manually accept or dismiss a specific dialog by its ID. Use for interactive dialog handling instead of automatic actions. For prompt dialogs, can provide response text when accepting.
When to use browser_handle_dialog
Use browser_handle_dialog when you need to handle native JavaScript alerts, confirms, and prompts. It is part of Owl Browser's Dialog Handling toolset and runs inside a self-hosted, source-level stealth engine, so every call inherits the same undetectable browser fingerprint as the rest of your automation — no separate anti-detect setup required.
Usage Example
Parameters
Required
dialog_idstringrequiredThe unique identifier of the dialog to handle, obtained from browser_get_pending_dialog or browser_wait_for_dialog
acceptbooleanrequiredSet to true to accept (click OK/Yes) or false to dismiss (click Cancel/No) the dialog
Optional
context_idstringThe browser context that owns the dialog (from browser_get_pending_dialog). Required for correct routing in multi-process mode; the dialog lives on the context's browser process
response_textstringText to enter in prompt dialogs before accepting. Only applicable for prompt dialogs when accept=true. Ignored for alert and confirm dialogs
Response
Returns a JSON object with the operation result.
{
"success": true,
"result": <value>
}Frequently Asked Questions
What does browser_handle_dialog do?
Manually accept or dismiss a specific dialog by its ID. Use for interactive dialog handling instead of automatic actions. For prompt dialogs, can provide response text when accepting. It belongs to Owl Browser's Dialog Handling category and is available through the REST API, the Python SDK (browser.handle_dialog()), the Node.js SDK, and the MCP server.
What parameters does browser_handle_dialog accept?
browser_handle_dialog accepts 2 required parameters (dialog_id, accept) and 2 optional parameters. All parameters are sent as JSON in a POST request to /api/execute/browser_handle_dialog.
Is browser_handle_dialog detectable by anti-bot systems like Cloudflare or DataDome?
No. browser_handle_dialog executes inside Owl Browser's Chromium engine, which applies fingerprint spoofing at the C++ source level rather than through JavaScript patches. Every tool call shares the same consistent, human-like fingerprint, so anti-bot systems such as Cloudflare, DataDome, and Akamai see an ordinary browser.
Related Tools
browser_set_dialog_actionConfigure automatic handling for JavaScript dialogs (alert, confirm, prompt, beforeunload). Set once and all future dialogs of that type are handled automatically. Useful for preventing dialog interruptions during automated browsing. Each dialog type can have a different action.
browser_get_pending_dialogCheck if there's a JavaScript dialog currently waiting for user action. Returns dialog type, message, default prompt value, and dialog ID. Returns null/empty if no dialog is pending.
browser_get_dialogsGet all dialog events that have occurred in the context, including handled and pending dialogs. Useful for reviewing dialog history and debugging dialog handling.
browser_create_contextCreate a new isolated browser context with its own cookies, storage, and optional proxy configuration. Each context acts as an independent browser session. Use this to create multiple isolated browsing sessions, configure proxy/Tor connections, load browser profiles with saved fingerprints, and enable/disable LLM features. Returns a context_id to use with other browser tools.
browser_navigateNavigate the browser to a specified URL. This is a non-blocking operation that starts navigation and returns immediately. Use browser_wait_for_network_idle or browser_wait_for_selector to wait for the page to fully load. Supports HTTP, HTTPS, file, and data URLs. When wait_until is set (load, networkidle, fullscroll, domcontentloaded) and the page declares WebMCP tools, the response includes a webmcp_tools array containing the full tool definitions (name, description, inputSchema). Use browser_webmcp_call_tool to execute any of these tools directly.
browser_observeAgent-native page observation. Returns the compacted OwlMark render (text-only structural view of the page), a handle table of interactive elements with stable tokens, page metadata, and a token estimate. Pass a handle token (e.g. 'b3') or 'pm:N' to browser_click/browser_type. Requires the context to be created with render_mode 'agent' or 'both'. ~20-100x fewer tokens than a screenshot for AI agent page understanding.