Selenium language bindings and browser drivers: implicit wait composition during explicit wait polling

Wait composition across the WebDriver boundary

Selenium WebDriver separates test logic in a language client from browser control in a driver such as ChromeDriver or GeckoDriver. An implicit wait configured on the driver persists for the session and causes findElement to poll the DOM until its timeout expires. An explicit wait built with WebDriverWait and an ExpectedCondition polls only that condition until its own timeout expires.

When both are active, a condition that calls findElement can trigger the implicit wait inside the explicit wait loop. The observed failure time may therefore exceed the explicit timeout, but the exact arithmetic is not uniformly pinned by the WebDriver protocol across browser vendors. ChromeDriver and GeckoDriver may compute combined wait durations differently, and behavior can change across driver versions.

Before relying on a shared driver instance for tests that mix wait strategies, the interaction needs to be characterized per driver and Selenium version. The uncertainty is whether the implicit wait is additive to each polling attempt, applied only to the final failed lookup, or handled in another driver-specific way.

What is the documented or observed wait-composition model for ChromeDriver versus GeckoDriver when an implicit wait is set and an explicit wait condition performs element lookups? Which Selenium and browser-driver version combinations have altered this behavior in supported releases? How should a test suite measure the actual timeout boundary without assuming the two waits are independent?