So this episode is going to be slightly different to previous episodes as this question came up this week. Why do browser vendors and the Selenium Project ship a driver executable? And Why do I need to update it with every browser release?
This is one of the biggest pain points I have seen people struggle with when using Selenium. The majority of the people who struggle are those who do not have a lot of experience programming. So why do we download this executable?
The driver you are downloading is an HTTP server for the client libraries to be able to speak to.
Unfortunately, as I mentioned in Episode 1, doing that increases the amount of work each binding maintainer needs to do and potentially limits who can write the bindings.
It also means any setup required for the browser needs to be done by the bindings. If you’re using a Chromium-based browser or Firefox, the bindings will need to know where to find the browser executable normally, as well as make sure the profile directory is created properly. It also puts the onus of fixing any breaking changes the browser vendors do to their startup setups on to each of the binding maintainers.
Trust me, the Selenium Project used to do that and every browser release day meant a mad scramble. We would start running tests in an attempt to make sure nothing was broken. We would fix the problems and then release. This herculean effort by core contributors meant we were limited in adding new features.
Not having to scramble and making sure it was simple for client binding maintainers to keep up to date was a great push for creating the WebDriver Specification.
Well… This is something we have wanted to implement in the past but we haven’t had time. Fortunately, there have been other projects that have come along and made this work easier. In the future, we are likely to try to incorporate one of these projects or we might look to see about implementing something ourselves.
This will be something we will try look into once we have shipped Selenium 4.