SeleniumLibrary: StaleElementReferenceException with Wait* keywords

The reason I think Wait ... keywords could ignore the stale element errors is that they already ignore errors related to elements not existing in the first place. In practice these keywords execute conditions like self.find_element(locator).is_visible(). At the moment it’s fine if find_element() fails due to element not existing, but it’s a failure if element exists but is invalidated before calling is_visible().

In my opinion element not existing and element being invalid are so close to each others that they should be handled the same way. They both cause a failure with normal keywords, and I see no harm in both of them being ignored with wait keywords. If I’ve understood it correctly, now wait keyword passing or failing may depend on timing.

As I wrote above, I think these two error situations should be handled the same way. That could be easily and explicitly done like this:

    def _wait_until_worker(self, condition, timeout, default_error):
        max_time = time.time() + timeout
        error = None
        while time.time() < max_time:
            try:
                if condition():
                    return
            except (ElementNotFound, StaleElementReferenceException) as err:
                error = str(err)
            else:
                error = None
            time.sleep(0.2)
        raise AssertionError(error or default_error)

PS: That str(err) should actually be unicode(err) to avoid non-ASCII errors with Python 2.

User’s perspective: I’ve just spent a year in a shop dealing with apps written using a framework which was basically a stale element exception generator (SAPUI5, may you burn in hell). We used the SL monkeypatched to do exactly what Pekka posted above, and it was totally fine for us. We somehow knew the behavior is sort-of wrong but we were not able to fix the framework that caused the problems (different team, big corp). As you say, especially with Wait keywords it’s really a nuisance because when you are waiting on some transition, you kinda expect funky things to happen in the meantime in the DOM.

Holding my thumbs that a fix for this long-runner makes it into v3.3.0. That would be awesome. Thanks @aaltat and everybody else for your dedicated work with RF.

There is actually good reason why it happens randomly and why it happens “Wait Until Element Is Visible”. Understanding both of these, helps one to understand how to fix it and why fixing is actually so darn difficult.

In most of the selenium operations, like Clicks and "Wait Until Element Is Visible, there is actually two operations over the json wire protocol (from S2L to the browser). First one will locate the element and return reference to the element. Second operation will perform the click, based on the element reference. When the click is received, in the browser, selenium will check is the element reference still valid. If it’s not valid, error will be received.

The Webdriver wait functionality tries to remove the problem by allowing poll the element staleness. And polling will return when the element state is not anymore stale.

But thanks to modern browser technologies, element state is wery moving target. Example in a filter box, user types N number of letters and results is filtered. Now depending on the implementation of the application, element state can change from N * 2 (each key stroke causes state to change stale and back) to 0 (no filtering was required). Because it is impossible to know how many stale state change one should poll and how long one should wait, to be sure that error is not received it is hard to come up with universal solution to the problem.

But I am thinking and have prototypes for few solutions, but they all have their problems. And all of them require massive rewrite. But thanks from understanding and patience on the matter.