Need help handling StaleElementReferenceException - selenium

Question

Before we get started let me say I have done my research on this matter, and I have seen the solutions posted here: stale element solution one, and I even came up with my own solution here: My temporary solution the problem with my solutions is that it does not work for all cases (particularly when dealing with long chains of .children()
The problem I have with "stale element solution one" is that it is not a very robust solution at all. It only works if you can put your Navigator element instantiation inside of the try catch, but if you do not have that instantiation, then this solution does no good. let me give an example of what I mean.
Lets say i have a Page class that looks something like this:
package interfaces
import geb.Page
import geb.navigator.Navigator
import org.openqa.selenium.By
class TabledPage extends Page {
static content ={
table {$(By.xpath("//tbody"))}
headers {$(By.xpath("//thead"))}
}
Navigator getAllRows(){
return table.children()
}
Navigator getRow(int index){
return table.children()[index]
}
Navigator getRow(String name){
return table.children().find{it.text().matches(~/.*\b${name}\b.*/)}
}
Navigator getColumn(Navigator row, int column){
return row.children()[column]
}
}
lets say that I have a method in my script that does what "stale element solution one" does (more or less). That looks like this:
def staleWraper(Closure c, args = null, attempts = 5){
def working = false
def trys = 0
while(!working){
try{
if(args){
return c(args)
}
else{
return c()
}
}
catch(StaleElementReferenceException se){
println("I caught me a stale element this many times: ${trys}")
if(trys>attempts){
working = true
throw se
}
else{
trys++
}
}
}
}
The way you call the above method is like this (using TabledPage as an example: staleWrapper(TabledPage.&getRow, 5) //grabs the 4th row of the table
and this works fine reason being, and this is important, the getRowmethod references an element that is in static content. When an static content element is reference, the Navigator is re-defined at run time. this is why this solution works for the getRow method. (table is re-instantiated inside of the try catch)
my problem and gripe with "stale element solution one" is that this type of implementation does not work for methods like getColumn this is because getColumn does not reference the static content itself. The Tabled page I am testing has javascript running on it that refreshes the DOM multiple times per second. so even if I use the staleWraper method it will always throw a stale element no matter how many attempts are made.
One solution to this is to add the columns as static content for the page, but I want to avoid that because it just doesn't flow with the way I have my whole project setup (I have many Page objects that implement methods in a similar way to TabledPage) If it were up to me, there would be a way to suppress the staleElelementExcpetions, but that is not an option either.
I am wondering if anyone here has a creative solution to Robustly (key word here) handle the StaleElementException, because I think looping over a try catch is already kinda hacky.

Answer 1

Well, I am not sure if my solution will solve your purpose. In my case I am using Page Pattern to design the tests so each method of Page class uses PageFactory to return instance of Page class. For example,
public class GoogleSearchPage {
// The element is now looked up using the name attribute
#FindBy(how = How.NAME, using = "q")
private WebElement searchBox;
public SearchResultPage searchFor(String text) {
// We continue using the element just as before
searchBox.sendKeys(text);
searchBox.submit();
// Return page instance of SearchResultPage class
return PageFactory.initElements(driver, SearchResultPage.class);
}
public GoogleSearchPage lookForAutoSuggestions(String text) {
// Do something
// Return page instance of itself as this method does not change the page
return PageFactory.initElements(driver, GoogleSearchPage.class);
}
}
The lookForAutoSuggestions may throw StaleElementException which is taken care by the returning the page instance. So if you are having page classes then ideally each page method should return an instance of page where user is supposed to land.

Answer 2

I ended up implementing something similar to what this guy gives as the "3rd option": Look at the answer (option 3)
I need to test it out some more but I have yet to get stale element since I implemented it this way (the key was to make my own WebElement class and then override the Navigator classes but use the NeverStaleWebElement object instead of the WebElement class