Provide a way to set Firefox log options

[lgrahl]

It's possible to set log levels for the geckodriver itself via {"moz:firefoxOptions": {"log": {"level": "..."}}} but there's no way to set specific log options for Firefox in a convenient manner.

I'd like to be able to set things such as the following logging options:

export R_LOG_LEVEL=3
export R_LOG_VERBOSE=1
export NSPR_LOG_MODULES=DataChannel:5,SCTP:3

I could set those before running geckodriver but take the following scenario: I have a Selenium Grid and I want to run a test that requires Firefox logging output for analysis from specific modules, such as DataChannel or SCTP. I could apply those environment variables to the running environment but with Selenium Grid I don't control environment variables on the executing node.

I guess it would be sufficient to provide a way to set those environment variables by additional arguments (granted, Selenium Grid could also provide a way to just set environment variables remotely).

[andreastt]

The WebDriver standard does make it possible for Selenium Grid to define an extension capability that could be used for passing on variables to the environment that runs geckodriver. Like you suggested, that might be a more generic solution than building it into each driver (and would also let you set things like RUST_LOG for geckodriver).

Strawman proposal:

{"capabilities":
  "alwaysMatch": {
    "grid:env": {
      "NSPR_LOG_MODULES": "DataChannel:5,SCTP:3",
      "RUST_BACKTRACE: "1"
    }
  }
}

[davehunt]

Wouldn't this only solve the problem for Selenium Grid? What about other users that want to control the log levels of Firefox on a per session basis?

[andreastt]

They can presumably set it in their own environment. No special provisions need to be made if the Firefox instance runs on the local system.

[davehunt]

There are more options than local and grid. What about a remote server instance, or Docker?

[andreastt]

I think in both those cases you have direct control over the environment?

My concern is that gluing propagation of environment variables on to capabilities specifically for one driver implementation will not solve all use cases and will cause ample confusion. Environment variables are not well understood by users and abstracting them on top of capabilities to communicate configuration for a narrow subset of processes (specifically, Firefox and its subprocesses) on a foreign machine does not make the distinction clearer.

My feeling is that environment propagation is beyond the scope of what a driver should offer, primarily because you can imagine wanting to also have variables that affect the driver itself and because the problem only exists for remote systems. I don’t think adding more entry-points for driver-specific configuration is a good idea because there are already a plethora of them that take various presedences (defaults, flags, capabilities negotiation of alwaysMatch then the array of firstMatches, preferences, inherited environment).

[davehunt]

I think in both those cases you have direct control over the environment?

No, not necessarily. I have the same concerns and opinions regarding environment variables, but I feel solving it just for Selenium Grid would more than likely cause more confusion and frustration, not less.

[andreastt]

No, not necessarily. I have the same concerns and opinions regarding environment variables, but I feel solving it just for Selenium Grid would more than likely cause more confusion and frustration, not less.

Propagating environment variables is a task that only makes sense in the sort of distributed environment that Grid provides. With Docker you use docker run -e FOO="bar" to set environment variables for the container. A remote server instance is not dissimilar to Grid, in that they are both intermediary nodes. Perhaps it should apply to all intermediaries.

---

Let me illustrate what I fear will happen. We often tell users to put geckodriver on their PATH. I posit that if we expose a dictionary on moz:firefoxOptions for environment variables, users may try providing entries such as {"moz:firefoxOptions": {"env": {"PATH": "/path/to/geckodriver:$PATH"}}}, falsely believing this will (1) add geckodriver to the system execution path and (2) expand the PATH variable.

[lgrahl]

Feel free to close this if you two both agree that it's something that should be done in Selenium. I've opened an issue there as well (see above).

[davehunt]

Rather than allowing arbitrary environment variables, could we support additional capabilities, which are translated into the necessary environment variables? If there's only a handful, and they related specifically to Firefox, I think this could be maintainable.

I'm thinking, for example:

{"moz:firefoxOptions": {
  "R_LOG_LEVEL": 3,
  "R_LOG_VERBOSE": 1,
  "NSPR_LOG_MODULES": "DataChannel:5,SCTP:3"}
}