The JavaScript “solution” offered for the following situation is BAD and should not be promoted as a solution or even a workaround.
“org.openqa.selenium.WebDriverException: Element is not clickable at point (x, y). Other element would receive the click: …”
Click-prevention techniques (overlays, spinners) are used to control application state while the application is in a state of transition. Using any mechanism to subvert the intentions of the app developer places the application into an unknown state – a state the developer has deliberately guarded against – and renders the test case meaningless. (See Tip: DO NOT CHANGE THE AUT THROUGH TEST CODE).
Scenario
The user causes the app to make a request for more data.
The app uses async XHR/ajax to fulfill the request.
The app puts up a spinner, blocking the UI.
The server fails at some point.
The async fail handler receives an HTTP 500 and tries to deal with it.
Using the suggestion above, the TC has already moved on, dealing now with a broken page that doesn’t know its own state.
The test developer tries to figure out why the TC is now failing somewhere else receiving errors that make no sense.
@Jass @duyluong @ThanhTo Please remove this suggestion from the docs.
What’s needed is a way to detect reasons why a spinner gets “stuck”.