🚨 Common Errors & Solutions

Common Errors & Solutions: Selenium error messages behave like Java's checked exceptions: you read the message at face value, look in the wrong place, and spend hours debugging.

Selenium error messages behave like Java's checked exceptions: you read the message at face value, look in the wrong place, and spend hours debugging. For example, NoSuchElementException looks like "your locator is wrong" — but most of the time the locator is correct and the element simply has not been added to the DOM yet, analogous to reading a Java Future without calling .get() first. If these errors are documented and well-known, why does everyone fall into the same traps? Because the error message reports the symptom, not the root cause: "Unable to locate element" makes the mind jump to "fix the locator," but the actual problem is usually timing, a missing iframe context switch, or a DOM re-render. StaleElementReferenceException is like accessing a Java WeakReference after garbage collection: the element was captured, the DOM re-rendered, and the reference is no longer valid — papering over it with another findElement hides the problem. In QA, accumulating these errors produces flaky test reports: CI appears green but the same test passes intermittently; this unreliability creates a culture where the team ignores all test results, which is far more dangerous than a test suite that simply fails.

🎬 The Diagnosis Chain of a Selenium Error: StaleElementReferenceException

Element found and captured

StaleElementReferenceException

The "just findElement again" reflex

Re-find BEFORE each use

Stability via WebDriverWait

`WebElement btn = driver.findElement(By.id("btn"))` — the element is found and STORED in a Java reference.

Step 1 — DECOMPOSE the message: "stale element reference: element is not attached to the page document" — this is not a locator error, it is a LIFETIME error.

A SPA like React/Vue re-renders the DOM in the background — perhaps visually identical, but TECHNICALLY a brand new element tree.

Step 2 — the Java bridge: this is exactly like accessing a `WeakReference` after GC — you still hold the reference, but the object it points to is GONE.

Contrast — the common wrong reflex: catching and saying "just findElement again" HIDES the problem but still risks going stale at the same spot again — patching without understanding the root cause.

Step 3 — the smallest SAFE fix: re-find the element IMMEDIATELY BEFORE each use, never capture it ahead of time and store it.

Step 4 — PROVE it with the SAME command: wrapping this call with `WebDriverWait` + `elementToBeClickable` solves both the stale reference and the timing issue at once.