Feature and motivation

As I'm working on alternative ways to implement #11376, I'm seeing a lot of differences in how the drivers are getting handled between browsers & languages.

Language Differences

Nothing shocking here.

• Ruby & Python let you pass in whatever args you want in a list; everything is in user's hands.
• .NET requires adding explicit support via Properties in Service classes; straightforward, but obviously we're now missing things as stuff changes.
• Java is even more fun because of the Grid. Each argument can be specified as a System Property or explicitly in the DriverService.Builder().

Browser Differences

Here's where it gets a little weird. Most of the things you set via Service classes are logging related, so that's what this is focusing on. I'm focusing on Java because it's the hardest use case, but most of this stuff applies in all the bindings.

• Firefox - you can set {"moz:firefoxOptions": {"log": {"level": "trace"}}}, but this only tells the driver to turn on logging. If you are running locally, this gets sent to stdout in your executing code, but if you are running remotely, it gets sent to stdout in the grid console (which the client can't access). The above capabilities output the exact same thing locally as starting geckodriver with --log trace. You can't set a logfile in the driver arguments directly, but Java has an extra method on the DriverService.Builder() class that will pipe stdout to a file or dev/null to simulate this; not all of the other languages do this right now, and we probably want to ensure this is possible.

• Chrome - Java added an implementation so log level can be set in ChromeOptions the same as in FirefoxOptions, and then if you pass that to the DriverService with ChromeDriverService service = ChromeDriverService.createServiceWithConfig(options), and pass that service variable as an argument to ChromeDriver it sets the argument on the driver, and essentially works the same as Firefox.

• Edge doesn't do what Chrome does, setting log level requires using a EdgeDriverService.Builder() method. I created [java] allow Edge to set driver log level as well #11404 thinking to add the same functionality to Edge that Chrome has, but... is this the right way to do this? It feels weird to add methods to an Options class that only get consumed by a Service class and are only applicable locally.

• Safari - we don't have it implemented anywhere (yet), but you can pass --diagnose to the safaridriver, and the results end up in ~/Library/Logs/com.apple.WebDriver/. 🤯

• IE - also has ability to pass in --log-level to Service class, haven't spent any time with it, yet, because VMs are a pain.

Now What?

Alternatives:

1. Take ChromeOptions implementation & expand it to EdgeOptions, leave everything else the same and it's good enough
2. Deprecate ChromeOptions implementation, require everything in DriverService.Builder, except Firefox, which is special
3. Deprecate for all Options classes and tell people to set it on the Service class because that's the only place it can actually used (Users can set driver arguments in grid if they have access to grid console logs directly)
4. Add driver logging methods to all of the Options classes and have the DriverService classes consume them directly by default. (One advantage of this is that we're probably going to do something like this anyway to support SeleniumManager methods).

Really, I wish there were an easy way for Grid to take the provided options parameters and turn on the various driver logging mechanisms and provide that info back to the user. It's pretty frustrating how little information the client can get back from the grid (#10949), especially since with how Java client does the streaming, we can really only get logs of intentions instead of what is actually getting sent.