Synchronization Model

FluentWait is Selenium's configurable wait. withTimeout sets how long it keeps trying, pollingEvery sets the gap between tries, ignoring and ignoreAll list exception types to swallow and retry, and withMessage sets the timeout text.

Wait times become unpredictable. Selenium's documentation warns against mixing the two, and gives the example of a 10-second implicit wait with a 15-second explicit wait producing a timeout after 20 seconds.

By calling a method on the reference each poll and watching for it to fail. Selenium 4 calls isEnabled and discards the result; when that raises a stale element reference or no such element error, the condition returns true.

Helpers that ask for a node return it: presenceOfElementLocated, visibilityOfElementLocated, visibilityOf and elementToBeClickable give a WebElement, the all-elements helpers give a list, alertIsPresent gives an Alert. Helpers that assert a page fact, such as invisibilityOfElementLocated, stalenessOf and titleIs, give only a Boolean.

Selenium's pageLoadStrategy picks which document readiness state a navigation waits for: normal waits for complete, eager waits for interactive, and none returns straight away. Normal is the default in Selenium 4.

Because the two ask different questions at different moments. The wait only confirmed displayed and enabled; obstruction is checked by the browser when the click command runs, and the page is free to change in between.

or() passes when any branch is satisfied, and() when every branch is, and not() when the wrapped one is not. All three yield a Boolean, losing any element. refreshed() wraps a single condition, keeps its return type, and absorbs staleness so the poll retries.

A function from WebDriver to some value. The wait passes the driver in on every poll, and the first result that is neither null nor false ends the wait and becomes the return value of until.

Cast the driver the wait hands you to JavascriptExecutor and return the result of executeScript from the condition. The fragment needs an explicit return statement, or every poll receives null and the wait just times out.

presenceOfElementLocated only requires the element to exist in the DOM. visibilityOfElementLocated additionally requires it to be displayed with a non-zero box. elementToBeClickable requires that displayed state plus the element reporting itself as enabled.

The wait throws org.openqa.selenium.TimeoutException. Its message names the condition it was waiting on plus the timeout and interval in force, and any exception the last attempt threw is attached as the cause.

WebDriverWait repeatedly applies the condition from the test process until it produces a usable value, which until() then returns. If the deadline passes first, the wait throws TimeoutException instead of returning.

Selenium's page load timeout caps how long a navigation command may block before the driver gives up and raises TimeoutException. The W3C default is 300,000 milliseconds, five minutes, and Selenium 4 takes it as a Duration.

Because presence only means the lookup succeeded. Selenium's presenceOfElementLocated calls findElement and returns whatever it finds; it never calls isDisplayed, so a node hidden by CSS or a collapsed parent satisfies it immediately.

Only two: null, and a Boolean whose value is false. Every other result ends the wait and is returned by until, including an empty list, an empty string and a zero, which is why an empty findElements result never waits.

Three states satisfy it: the element is found but not displayed, the locator matches nothing, or the element went stale mid-check. It returns a Boolean, not the element, and passes instantly when the locator never matched.

The wait checks the clock only between attempts, never during one. It evaluates the condition first, so an attempt that starts just before the deadline runs to completion, and total elapsed time is the timeout plus that final attempt.

Because pollingEvery sets a sleep between attempts, not a fixed cadence. The time the condition itself takes is added on top, so the real gap is the evaluation time plus the interval.

It blocks for the full ten seconds and then returns an empty list without throwing. The driver keeps retrying while the result is empty, so proving that nothing matches always costs the whole timeout.

The loop runs in the driver on the remote end, not in the client library. The value is session state, so it applies to every later element search on that driver until something changes it or the session ends.

Each poll of the explicit wait runs a find that the remote end retries for the full implicit wait, and Selenium checks the deadline only after a poll returns, so the last poll overshoots it.

Selenium's invisibility condition succeeds by catching a not-found error from findElement. With an implicit wait set, the remote end retries the lookup for the whole implicit timeout before reporting not-found, so every success pays that cost.

The condition is re-evaluated on every poll until it succeeds or times out, so any action inside it runs many times over. Selenium documents conditions as idempotent: keep the body to reads and act after until returns.

The lambda captured an element handle taken before the page re-rendered, so a later poll touches a detached node. WebDriverWait ignores only NotFoundException by default, and staleness is not one, so it aborts the wait.

WebDriverWait registers NotFoundException as ignored, so every not-found thrown inside the condition is caught, recorded and retried until the deadline. The recorded exception then becomes the cause of the TimeoutException the wait finally throws.

Almost every Selenium error subclasses WebDriverException, so stale elements, intercepted clicks, bad selectors, script errors and even a dead session are now retried in silence. The only failure left is a TimeoutException that names nothing.

Read the session's real script timeout with getScriptTimeout() first. It is session state an earlier test may have lowered, drivers differ from the specified 30 second default, and the exception only means the callback never fired.

It sets how long the browser driver keeps retrying an element search before giving up, for every search in that session. The default is zero, so an unmatched locator fails immediately.

Because an implicit wait only governs the search that locates an element. Once the element is found the wait is finished, and reading its text is a separate command that returns whatever the page says at that moment.