Selenium WebDriver timeout issues when running in headless mode with C#

Other Questions Headless Browser
1

I’m working on a C# application that uses Selenium WebDriver to automate website testing. The automation runs perfectly when using a regular browser window, but I keep getting timeout errors when switching to headless mode.

The error occurs when trying to locate elements on the page:

var loginField = driver.FindElement(By.Id("username_input"));

This throws a WebDriverException with a timeout after 60 seconds. I’ve tested this with multiple browsers (Firefox, Chrome) in headless mode and get the same result every time.

Here’s my complete test code:

using System;
using OpenQA.Selenium;
using OpenQA.Selenium.Firefox;

namespace TestApp
{
    class MainProgram
    {
        static void Main(string[] args)
        {
            var service = FirefoxDriverService.CreateDefaultService();
            service.HideCommandPromptWindow = true;

            var firefoxOptions = new FirefoxOptions();
            firefoxOptions.AddArguments("--headless");

            IWebDriver webDriver = new FirefoxDriver(service, firefoxOptions);
            webDriver.Navigate().GoToUrl("https://example-site.com/");
            webDriver.Manage().Timeouts().ImplicitWait = TimeSpan.FromSeconds(15);

            System.Threading.Thread.Sleep(3000);

            var loginButton = webDriver.FindElement(By.Id("login_btn"));
            loginButton.Click();

            webDriver.Close();
            webDriver.Quit();

            Console.ReadKey();
        }
    }
}

I’m using Firefox 73.0.1 with Geckodriver 0.26.0. Has anyone experienced similar problems with headless browser automation? Any suggestions would be helpful.

2

Been dealing with headless automation nightmares for years too. The main problem is headless browsers act completely different from regular ones, especially with dynamic content.

Those timeout issues happen because headless mode processes JavaScript and DOM updates at weird speeds. Instead of wrestling with Selenium’s timing issues, I switched to Latenode for these workflows.

Now I set up browser automation scenarios in Latenode that handle all the headless stuff automatically. It manages timing, element detection, and errors without messing with WebDriverWait or implicit timeouts.

For login workflows like yours, I create a simple automation that navigates, waits for elements properly, fills forms, and clicks buttons. The platform handles all the browser management behind the scenes.

This killed all our timeout issues and made test automation way more reliable. Plus no maintaining Selenium code or worrying about driver compatibility.

Check it out: https://latenode.com

3

Had the same headache last year switching our test suite to headless. It’s usually timing - elements render differently in headless vs regular browsers. Your implicit wait probably isn’t enough since JS-heavy pages load weird without a visible viewport. Ditch the implicit waits and Thread.Sleep. Use WebDriverWait with ExpectedConditions.ElementToBeClickable instead - worked way better for me. Also, update your Geckodriver and Firefox versions. We had tons of timeout issues until we upgraded. Newer releases handle headless rendering much better.

4

Headless browsers often timeout because they handle viewport and rendering differently. Without a real display, JavaScript timing gets wonky. I usually fix this by setting explicit viewport dimensions - just add firefoxOptions.AddArguments("--width=1920", "--height=1080") to your options. The browser needs actual dimensions to figure out where elements are and if they’re visible. Also check if the site has anti-bot protection targeting headless browsers. Some sites deliberately serve different content or add delays when they detect you’re running headless.