Element Location

The find command searches one node tree from a single start node, and a shadow tree is a separate tree, so a descendant selector never reaches inside. Find the host, take its shadow root, search again from there.

Each findElement call is one HTTP command to the browser driver, sent as POST /session/{id}/element. A loop over 300 rows sends 300 separate commands, and those round trips add up no matter how simple the selector is.

Because a CSS selector matches on tags, ids, classes, attributes, structural position and state, never on the characters inside an element. Selenium sends the string straight to the browser's querySelectorAll, so a locator gets exactly that power and no more.

Selenium compares bounding rectangles edge to edge: a candidate is above an anchor only when the candidate's bottom edge sits at or higher than the anchor's top edge. Any overlap fails all four directional tests.

Selenium's near() keeps any element whose rectangle overlaps the anchor's rectangle grown by 50 pixels on every side, excluding the anchor itself. Results come back sorted by centre-to-centre distance, closest first.

A predicate attaches to the step in front of it and is evaluated once per context node, so //tr[1] keeps the first row under every parent. Parentheses index the finished node-set instead.

A CSS find makes the browser call querySelectorAll on its native selector engine. An XPath find makes it call evaluate in the separate DOM-XPath evaluator. Both run inside one WebDriver command, so the gap is usually tiny.

Five of them: By.cssSelector, By.linkText, By.partialLinkText, By.tagName and By.xpath. By.id, By.name and By.className have no W3C strategy, so the client turns each into an equivalent CSS selector instead.

Because id is not a WebDriver locator strategy. The Java client first tries sending using id, the remote end refuses it with invalid argument, and the client then repeats the lookup with the CSS fallback the By carries.

Yes, with the :has() relational pseudo-class, as long as the browser under test implements it. It still cannot test rendered text, so a lookup that depends on what an element reads must fall back to an XPath expression.

Absence and a broken locator look identical to Selenium: both produce no match. Check absence with findElements and isEmpty, and prove the same locator matches while the banner is present, or the assertion passes for the wrong reason.

A shadow root is a handle the browser resolves on every command, and it stays valid only while its host element does. Once the host is replaced the root is detached and every lookup through it fails.

Because the time is going into the number of commands, not the matching engine. Three hundred finds plus three hundred text reads is six hundred round trips, and a faster in-page match saves only microseconds on each one.

It runs inside the page. Selenium injects a bundled JavaScript atom with one execute-script call, which resolves the locators and reads every rectangle. So matching semantics are pinned to your client version, not to the browser driver.

Nothing checks the string locally. It travels to the browser, which runs querySelectorAll with it; the parse failure comes back as the invalid selector error and the Java client raises InvalidSelectorException, which is not the same as NoSuchElementException.

Selenium's WebDriver and WebElement both implement SearchContext, so an element can start a search of its own. A find called on an element sends a find-from-element command and searches only that element's descendants.

It returns a SearchContext for the element's shadow root, so the only things you can call on it are findElement and findElements. It is not a WebElement, so there is nothing on it to click or read text from.

An absolute XPath spells out every step from the document root, such as /html/body/table/tbody/tr[2]/td[1]. A path starting with a double slash searches the whole document and matches at any depth.

Compound class names are rejected. The By.className constructor checks the value for whitespace and throws InvalidSelectorException immediately, because its CSS fallback is a single class selector that could never match two tokens.

A pseudo-element is generated by the style engine and never becomes a DOM node, so the browser's querySelectorAll cannot return one and Selenium has nothing to wrap in a WebElement. Read it with getComputedStyle inside an injected script instead.

It returns element zero of the match list in document order and never signals that others matched, so the test acts on the first row and still passes. Only counting the plural call reveals the ambiguity.

A leading slash in XPath means the document root, not the element you are searching from. The element is used only to find the document, so the expression scans the whole page. Start it with a dot instead.

You cross one boundary at a time: find the outer host, take its root, find the inner host inside that root, take its root, then find your element. That is five commands.

Escaping. Selenium rewrites By.id into a CSS selector but escapes the value first, so the dot stays a literal character of the id. A hand-written selector reads that same dot as a class instead.

Bisect the chain: run the root locator alone, then with each filter added, to find which filter empties the set. Then compare the anchor and candidate rectangles, since the directional filters reject any overlap.

The ancestor axis is a reverse axis, so XPath numbers its positions outward from the context node: index 1 is the closest matching ancestor, not the outermost. Forward axes number in document order instead.

It is re-evaluated from the document root on every call, because WebDriver hands the expression to the browser afresh each time. The walk is cheap per step; a leading double slash is what costs.

Selenium has no strict-match mode, so enforcing one means a helper that calls findElements and fails unless exactly one element matched. That turns silent wrong-target bugs into loud failures, but rejects legitimately repeated markup.

It never returns null. Selenium's findElement throws NoSuchElementException when nothing matches, so a null check after it is unreachable code, while the plural findElements returns an empty list instead of throwing.