Suggestion: adding optional parameters to find_element() and related methods in Python binding

[dcavanaugh]

AJAX-related problems with find_element()

I have some Python code (which my employer has authorized me to release under the Apache 2.0 license). By modifying webdriver.py, it is possible to change the behavior of find_element() and related methods when additional parameters are present. The goal is to selectively invoke WebDriverWait() instead of self.execute(Command.FIND_ELEMENT) when the parameters include an optional timeout parameter with a value greater than the default value of 0.

Why would anyone want to do this? When using a script recorder like Selenium Builder with an AJAX web application, there will be a failed call to find_element() whenever the script is looking for an element that has not loaded yet.

Example:

wd = webdriver.Firefox()
wd.find_element_by_id("my-element-id").click()

Fails when the element is not yet in the DOM because it loads dynamically in response to user input

Workaround #1:

element = WebDriverWait(wd, timeout ).until( expected_conditions.element_to_be_clickable( ( By.ID, “my-element-id” ) ) )
element.click()

Workaround #2:

errCount = 0
while errCount < 5:
    try:
        wd.find_element_by_id("my-element-id").click()
        break
    except:
        time.sleep(5)
        errCount += 1
        continue

Proposed Solution

Neither of the above-mentioned workarounds is desirable because of the number of times it has to be coded into the script for a typical AJAX web application. Instead, it would be better to find a quick way to fix broken find_element() calls.
Example:

wd = webdriver.Firefox()
wd.find_element_by_id("my-element-id").click()

Breaks if we look for the element before the server renders it

wd.find_element_by_id("my-element-id",10,”clickable”).click()

Succeeds because of modifications to webdriver.py; using WebDriverWait with a 10 second time limit for the element to become clickable.

I have code that implements the concept; will attempt to demonstrate in a branch.

[cgoldberg]

-1

The first workaround shown seems fine to me as is. I don't see the advantage over just combining a WebDriverWait and ExpectedConditions:

WebDriverWait(driver, 10).until(EC.element_to_be_clickable((By.ID, id))).click()

[dcavanaugh]

It all boils down to how many broken calls to find_element() are in your script and how many scripts you have. Which is easier? Adding parameters like 10 and "clickable" or replacing the call to find_element() with WebDriverWait? If you have enough scripts with a enough broken calls, it becomes a real nuisance.

[cgoldberg]

Which is easier?

that is totally irrelevant here. you are proposing to change the API just to save yourself from refactoring?

[dcavanaugh]

The API would have to preserve existing behavior for compatibility with existing scripts. But yes, I would make things easier. If script recording tools were smart enough to generate calls to WebDriverWait when it is needed, this wouldn't be an issue. Unfortunately they don't.

Now that both sides of the issue are represented, let's see if anyone else has an opinion.

[AutomatedTester]

This is not going to happen.

This is trying to move webdriverwait into the API in a hope, and a prayer, that it might do the right thing. You are hoping that the Halting Problem is going to be solved here. It's not.

The API already gives you things like implicit waits for elements being added to the DOM. Since there are a mirade of reasons why you want to wait, this complicates the client code. It doesn't complicate test code since you should already be using something to hide the Selenium implementation from your tests that allow you to make something useful. One such abstraction can be done with Page Objects.