Useful Flags for Chromedriver

Chromedriver is a powerful and flexible tool for remotely controlling a browser while testing your site for use interactions or as part of a crawler or other automated application. It has a lot of configuration options in the form of flags passed in on load which allow you a great deal of control over chrome or chromium’s behavior. Unfortunately, there are a lot of flags and navigating them can be a bit of a slog, so I wanted to outline a few flags which I’ve used in my own chromedriver adventures and found generally useful.



As you might expect, these modify the size of the browser window when chromedriver starts up. Trying to see what the browser is interacting with while it’s running? Toss in a --start-maximized for visibility. Trying to watch debug traffic or spec results in a terminal while chromedriver is running, or perhaps multiple browser windows running together? Set --window-size to a small value so you can keep things in sight (and, if rendering is wholly unnecessary, there’s always --headless).



If you want to use a proxy with your browser, that can be passed in as a flag to the browser. This does, however, result in a lot of SSL errors if you’re setting up a man-in-the-middle proxy (to analyze traffic, for instance). In normal browser operation, this throws up a blocking page to make sure the user knows their secured traffic is passing through a third party, but that can be an inconvenience if your automated browser needs to access https resources. Using --ignore-certificate-errors gets around this issue handily, allowing the browser to continue without that roadblock (though the page will still be marked insecure on the address bar).


Starts the browser in incognito mode. This prevents the cookie and local storage of browser windows from carrying over into one another, which is useful if you have tests running in parallel, for instance.


The devtools pane opens at start up. This is useful for checking for  errors in the javascript console, and is extra, extra useful if you’re chasing down problems with network requests in testing, as it will start recording immediately, rather than needing to grab the window, open devtools and then reload the page (possibly interrupting your own tests or other app activities).


This is a somewhat unusual one. Google’s account managing functions in chrome and chromium are built as gaia apps, and will try to ping the Google servers to sync account information. This can leads to some spurious open network connections if your automated application is monitoring those to check page loads. Routing this connection to a random external url will cause chrome to fail to boot, but if you really want to suppress this connection, you can set this value to a chrome:// url with a fake address. This will cause the browser to talk to itself when trying to sync, which will stop that external connection (but also break that piece of browser functionality).

These are just a small, small subset of available flags and options. A fairly complete list is available at this site for all your automation needs. Hopefully some of these will prove useful on your next browser automation project. Safe building!

*** This is a Security Bloggers Network syndicated blog from Tinfoil Security Blog authored by Alex Bullen. Read the original post at: