I have a few questions related to explicit waits:

  1. Is it possible to use more methods to same element?
  2. What combination of them I can use ?
  3. Why I still have exceptions with stale element and similar exceptions?

wait.Until(ExpectedConditions.VisibilityOfAllElementsLocatedBy(By.XPath("//tr[@id='messageGrid_DXDataRow0']/td[3]"))); wait.Until(ExpectedConditions.ElementToBeClickable(By.XPath("//tr[@id='messageGrid_DXDataRow0']/td[3]"))); driver.FindElement(By.XPath("//tr[@id='messageGrid_DXDataRow0']/td[3]")).Click();

  • You can do more than one thing with an element yes. I usually pull the element into a variable, but the expectedconditions work off the By. The element becomes "stale" when the reference no longer valid in the browser window. If you are utilizing a messageGrid this could be due to a dynamic update to the element from the last time you looked at it. Sometimes the update wil mark it as changed on the browser which will flag it as stale even though it was dynamically updated on the page itself without browser knowledge. So it's valid, but not registering as valid via the browser.
    – mutt
    Commented Mar 22, 2017 at 18:21
  • Can you include the HTML and any javascript rendering controls of the message grid in question? Sometimes javascript may be needed to find it and bypass the browser recognition part that selenium is utilizing.
    – mutt
    Commented Mar 22, 2017 at 18:22

2 Answers 2


Q: Is it possible to use more methods to same element?

A: You can do that, but you wouldn't need to. If you check for clickability, like in the code snippet you provided, selenium makes a check for elementToBeVisible and elementToBeEnabled. So, you don't have to write



Instead, just check for clickability and the visibility part will be automatically covered.

Q: Why I still have exceptions with stale element and similar exceptions?

A: Although, this que can be answered with absolute correctness only after seeing code snippet and the error, but, I'll tell you a likely scenario because of which you might be getting the error. - Your element becomes (visible and enabled) i.e. clickable and then the page loading takes place (like in case of a dashboard load or other async calls), making the element non visible and when you try to click a non-visible element that was clickable just a second before, you get StaleElementException.


Might be a little shameless to link my own repo... but this is a pattern I used for years in my previous jobs as an automation engineer.
This particular object represents a pattern that "proxies" web elements, creating disposable element references on the fly that get used once for a specific action, then is allowed to be garbage collected. Using this pattern, you can wrap your waits in methods to be chained.

Chaining this returning methods that each perform one type of wait can create cause->effect relations between your multiple conditions. Such as, an element can't contain text until it's first visible, and it can't be visible until it's present. So, while you don't need to explicitly check each of those states, if you find that when you want to get text, if you get NoSuchElementExceptions, you may want to first wait for presence, since the last action you performed might've triggered a relevant DOM mutation.



The reason I'm mentioning this even though it's not really a direct answer to what you're asking is because of your other question involving StaleElementReferenceExceptions. My desire to create a solution to minimize those was the driving factor for this pattern and led it's evolution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.