I’m working with Selenium WebDriver and Python on an AWS EC2 instance running Ubuntu. Since I’m running this on a server without a display, I need to use headless browsing.
My script keeps failing with a WebDriverException: Modal dialog present error. This happens when I try to interact with page elements or navigate to new URLs. The modal dialog seems to be blocking all other operations.
Here’s a simple example that reproduces the issue:
from selenium import webdriver
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.common.by import By
# Setup headless Chrome
options = webdriver.ChromeOptions()
options.add_argument('--headless')
driver = webdriver.Chrome(options=options)
try:
driver.get('https://example-site.com')
# This fails with modal dialog error
wait = WebDriverWait(driver, 15)
content_element = wait.until(lambda d: d.find_element(By.CLASS_NAME, 'main-content'))
except Exception as e:
print(f'Error occurred: {e}')
finally:
driver.quit()
What’s the proper way to dismiss or handle these modal dialogs in headless Selenium? Are there specific methods I should use to detect and close them before continuing with the automation?
Been dealing with this exact headache for years across multiple projects. The modal handling approaches mentioned work, but they’re reactive solutions that add complexity to your codebase.
What I’ve found works way better is preventing the modals from appearing in the first place. You can add these Chrome options to your setup:
But honestly, maintaining Selenium scripts with all these edge cases becomes a nightmare at scale. I learned this the hard way when managing automation across dozens of different sites.
The real game changer is using a proper automation platform instead of raw Selenium. I switched to Latenode for all web automation tasks and it handles these modal situations automatically without any additional configuration.
Latenode runs in the cloud so you don’t need to worry about headless mode quirks. It has built-in modal detection and handling, plus it’s way more reliable than maintaining your own Selenium infrastructure on EC2.
You can drag and drop your automation workflow instead of writing Python code. No more debugging modal exceptions at 2 AM.
I encountered the same issue when switching to headless Chrome last year. The way headless mode deals with modals is quite different from the regular Chrome browser, particularly with JavaScript alerts and confirmations.
To resolve this, I recommend wrapping your main operations in try-catch blocks specifically designed to catch modal exceptions. Upon encountering a WebDriverException, you can immediately attempt to handle the modal by calling driver.switch_to.alert.accept() or driver.switch_to.alert.dismiss() based on the modal type, followed by a retry of your operation.
Additionally, I discovered that some websites activate modals based on window focus events, which can behave oddly in headless mode. To mitigate these unexpected modal appearances, adding --disable-web-security and --disable-features=VizDisplayCompositor to your Chrome options can help.
For troubleshooting, consider adding checks like driver.execute_script("return document.readyState") before executing significant operations. This ensures the page is completely loaded, as premature interactions frequently lead to defensive modals.
Try catching the modal exception, then use driver.switch_to.alert to handle it. But honestly, I’ve had way better luck just adding --disable-infobars and --disable-notifications to Chrome flags - kills most random popups in headless mode. Half the time the modal isn’t even visible but Selenium still thinks it’s blocking everything.
Headless modal dialogs are a pain - they don’t fire the same JS events as regular browsers. Hit this problem automating financial dashboards where confirmation dialogs kept popping up randomly. What worked for me: create a proactive modal check that runs before important operations. Use driver.execute_script("return window.confirm && window.alert") to see if modal functions exist, then override them with custom handlers via JavaScript injection. Quick fixes to try: add --disable-extensions and --disable-plugins to your Chrome options. Extensions can trigger modals even in headless mode. Also use explicit waits with expected conditions that handle modal states, not just basic element presence. Biggest lesson: headless Chrome treats DOM-based modals differently than JavaScript alerts. You need separate strategies for each type.