Q35 of 37 · Selenium

Walk through how you'd test a feature requiring a specific browser version that's no longer in the official driver library.

SeleniumSeniorseleniumbrowser-versiondriversdockersenior

Short answer

Short answer: Pin the browser binary, find the matching driver from the vendor's download archive, configure the WebDriver with explicit binary + driver paths, and run in Docker so the version is reproducible. If it can't be supported safely, push back: testing on an unmaintained browser version may not be worth the risk.

Detail

This usually happens with a customer who's stuck on an old IE or pinned Chrome — or a partner integration with a fixed embedded browser.

Step 1 — Find the binary. Vendor sites archive old Chromium / Firefox versions. https://www.chromium.org/getting-involved/download-chromium lists builds; for Firefox, the https://archive.mozilla.org/pub/firefox/releases/ archive has every version. Download the exact version requested.

Step 2 — Find the matching driver. Driver-browser version compatibility is strict:

  • chromedriver: https://chromedriver.chromium.org/downloads (legacy) or https://googlechromelabs.github.io/chrome-for-testing/ (newer). Match major version exactly.
  • geckodriver (Firefox): the matrix at https://firefox-source-docs.mozilla.org/testing/geckodriver/Support.html.

If Selenium Manager won't auto-resolve (it usually won't for old versions), download manually.

Step 3 — Configure explicit paths:

ChromeOptions options = new ChromeOptions();
options.setBinary("/opt/chromium-104/chrome");

System.setProperty("webdriver.chrome.driver", "/opt/drivers/chromedriver-104");
WebDriver driver = new ChromeDriver(options);

Step 4 — Containerise — this is the only sane way to keep an old version reproducible:

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y libnss3 libxcb1 libgbm1 ...
COPY chromium-104/ /opt/chromium-104/
COPY chromedriver-104 /opt/drivers/chromedriver-104
ENV CHROME_BIN=/opt/chromium-104/chrome
ENV CHROMEDRIVER=/opt/drivers/chromedriver-104

CI runs the test container, version is pinned, no surprises from an OS update.

Step 5 — Push back if it's not worth it. Testing against a 4-year-old Chrome means:

  • That version no longer gets security patches — you may not be allowed to run it in some envs.
  • Real users on that version are exposed to known CVEs; a test pass doesn't make their experience safe.
  • The driver and bindings may have known-broken APIs for that combo.

The senior conversation with the product owner: "We can do this, here's the cost; alternatively, we could automate the modern flow and verify the legacy path manually once per release. Which is the right trade?"

Practical fallback: if it's just IE11 hold-out customers, IE Mode in Edge is officially supported and Selenium can drive Edge in IE Mode without going through this whole exercise.

// WHAT INTERVIEWERS LOOK FOR

A repeatable pinning strategy (binary + driver + Docker), the cultural willingness to push back on testing unsupported versions, and awareness of IE Mode as an out for the IE11 case.

// COMMON PITFALL

Trying to make Selenium Manager handle an arcane version, then wallpapering with workarounds. The right answer is explicit binary + driver paths in a pinned container — Manager is for the supported common case.