I was automating the script using headless(HtmlUnitDriver) browser but I wanted to know the limitations of headless(HtmlUnitDriver) browsers for example:

  1. Can headless browser deal with IFrames?
  2. Can headless browser perform upload files functionality?
  3. Can headless browser deal with alerts, pop-up windows?

Just like above questions I want to know what all functionalities which can be performed using actual browser but cannot be performed using headless(HtmlUnitDriver) browsers.

  • I have done headless browser testing using PhantomJs with Poltergiest driver in Cucumber-Capybara framework. The issue we were facing is random failures due to loading of page mainly due to ajax calls. So we had to add screenshots to verify the issues and add necessary wait for elements to load.
    – Sanchita
    Feb 24, 2016 at 12:33
  • That depends somewhat on how you define "headless browser" Do you have something that emulates a browser (eg: phantomjs) or are you using an actual browser on a headless machine (eg: firefox with xvfb). Can you clarify what you mean by "headless browser" Feb 24, 2016 at 12:59
  • @BryanOakley Selenium provides a headless browser called HtmlUnitDriver in which actual browser is not opened while executing script results can be seen only in console. Feb 24, 2016 at 13:10
  • 1
    @JeevanBhushetty: yes, I know. But "headless" can also mean using phantomjs, or a regular browser with a virtual display. The answer to the question depends on specifically what you mean by "headless". If you are specifically concerned with answers related to HtmlUnitDriver, you need to put that in your question. Feb 24, 2016 at 13:13
  • @BryanOakley Updated question. Feb 24, 2016 at 13:17

2 Answers 2


Headless browsers can do all the things you mentioned. The main discussion around headless browser these days is based around speed versus accuracy.

Some strengths of headless browsers:

  • Able to run far more instances simultaneously than non-headless drivers.
  • Can make use of large amounts of factory-generated or manually created test variables in Data-Driven Testing
  • Run-time can be reduced by up to 50% for most tasks.
  • Can be executed without taking up the screen context of a computer.

Some weaknesses:

  • Hard to debug inconsistent failures on locating elements due to page loading too fast
  • Unintended interactions (losing the benefit of automated UI testing vs integration or unit testing) due to speed/headless state of browser
  • Code for non-headless drivers will not always work when driver is switched to htmlunit. I.e. switching between ChromeDriver and FirefoxDriver is usually pretty consistent in success rate with same code, but switching to HtmlUnit might need extra tending to.


  • Speed vs Consistency - Higher failure rate not as big of a deal with screenshots on fail or tools like saucelabs which record entire runs.
  • More specific code vs more general code - Some pages/elements will need specific waits and tailoring in headless browsers, whereas it is pretty straightforward to code for nonheadless

Headless browsers can barely deal with iframes. I have found that if your iframe contains an entire workflows html, the headless driver cannot distinguish between two elements on different "pages" with the same css, where as non headless can

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.