Flags.md

Flags

--android-storage ANDROID_STORAGE

Selects the test data location on the Android device, eg. the Firefox profile. By default auto is used.

<style type="text/css"> table { width: 100%; margin-bottom: 2em; } table, th, td { border: solid gray 1px; } td, th { padding: 10px; text-align: left; vertical-align: middle; } td:nth-child(1), th:nth-child(1) { width: 10em; text-align: center; } </style>

Value	Description
auto	Best suitable location based on whether the device is rooted. If the device is rooted internal is used, otherwise app.
app	Location: /data/data/%androidPackage%/test_root Based on the androidPackage capability that is passed as part of moz:firefoxOptions when creating a new session. Commands that change data in the app's directory are executed using run-as. This requires that the installed app is debuggable.
internal	Location: /data/local/tmp/test_root The device must be rooted since when the app runs, files that are created in the profile, which is owned by the app user, cannot be changed by the shell user. Commands will be executed via su.
sdcard	Location: /mnt/sdcard/test_root This location is not supported on Android 11+ due to the changes related to scoped storage.

-b BINARY / --binary BINARY

Path to the Firefox binary to use. By default geckodriver tries to find and use the system installation of Firefox, but that behaviour can be changed by using this option. Note that the binary capability of the moz:firefoxOptions object that is passed when creating a new session will override this option.

On Linux systems it will use the first firefox binary found by searching the PATH environmental variable, which is roughly equivalent to calling whereis(1) and extracting the second column:

% whereis firefox
firefox: /usr/bin/firefox /usr/local/firefox

On macOS, the binary is found by looking for the first firefox-bin binary in the same fashion as on Linux systems. This means it is possible to also use PATH to control where geckodriver should find Firefox on macOS. It will then look for /Applications/Firefox.app.

On Windows systems, geckodriver looks for the system Firefox by scanning the Windows registry.

--connect-existing

Connect geckodriver to an existing Firefox instance. This means geckodriver will abstain from the default of starting a new Firefox session.

The existing Firefox instance must have [Marionette] enabled. To enable the remote protocol in Firefox, you can pass the -marionette flag. Unless the marionette.port preference has been user-set, Marionette will listen on port 2828. So when using --connect-existing it is likely you will also have to use --marionette-port to set the correct port.

--host HOST

Host to use for the WebDriver server. Defaults to 127.0.0.1.

--log LEVEL

Set the Gecko and geckodriver log level. Possible values are fatal, error, warn, info, config, debug, and trace.

--marionette-host HOST

Selects the host for geckodriver’s connection to the [Marionette] remote protocol. Defaults to 127.0.0.1.

--marionette-port PORT

Selects the port for geckodriver’s connection to the [Marionette] remote protocol.

In the default mode where geckodriver starts and manages the Firefox process, it will pick a free port assigned by the system and set the marionette.port preference in the profile.

When --connect-existing is used and the Firefox process is not under geckodriver’s control, it will simply connect to PORT.

-p PORT / --port PORT

Port to use for the WebDriver server. Defaults to 4444.

A helpful trick is that it is possible to bind to 0 to get the system to atomically assign a free port.

--jsdebugger

Attach browser toolbox debugger when Firefox starts. This is useful for debugging [Marionette] internals.

-v[v]

Increases the logging verbosity by to debug level when passing a single -v, or to trace level if -vv is passed. This is analogous to passing --log debug and --log trace, respectively.