In the WebDriver protocol, when a command fails because it can not
interact with the target element, an "element not interactable" error is
generated. It can be a transitive issue (for example, due to an
animation), so when the error is received the command should be tried
again, just like done, for example, with "ElementNotVisible" exceptions.
However, the last version of the "instaclick/php-webdriver" library
compatible with the Selenium Driver of Mink did not support yet that
WebDriver error. And even if Chrome is run using the old protocol an
unknown "element not interactable" error can be received anyway in some
cases. When an unknown error is received by the
"instaclick/php-webdriver" library it is thrown as a generic Exception
so, until the library can be updated, the message of generic exceptions
is checked and the command is retried if it matched.
For the time being "element not interactable" errors are handled like
"ElementNotVisible" exceptions; this may need to change once the error
is better understood.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
NoSuchElement exceptions are sometimes thrown instead of
StaleElementReference exceptions. This can happen when the Selenium2
driver for Mink performs an action on an element through the WebDriver
session instead of directly through the WebDriver element. In that case,
if the element with the given ID does not exist, a NoSuchElement
exception would be thrown instead of a StaleElementReference exception,
so those cases are handled like StaleElementReference exceptions.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
MoveTargetOutOfBounds exceptions are sometimes thrown instead of
ElementNotVisible exceptions. This can happen when the Selenium2 driver
for Mink moves the cursor on an element using the "moveto" method of the
Webdriver session, for example, before clicking on an element. In that
case, if the element is not visible, "moveto" would throw a
MoveTargetOutOfBounds exception instead of an ElementNotVisible
exception, so those cases are handled like ElementNotVisible exceptions.
Note that MoveTargetOutOfBounds exceptions could be thrown too if the
element was visible but "out of reach"; there is no problem in handling
those cases as if the element was not visible, as the exception will be
thrown again anyway once it is verified that the element is indeed
visible.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Commands executed on Mink elements may fail for several reasons.
ElementWrapper is introduced to automatically handle some of those
situations, like StaleElementReference exceptions and ElementNotVisible
exceptions.
StaleElementReference exceptions are thrown when the command is executed
on an element that is no longer attached to the DOM. When that happens
the ElementWrapper finds again the element and executes the command
again on the new element.
ElementNotVisible exceptions are thrown when the command requires the
element to be visible but the element is not. When that happens the
ElementWrapper waits for the element to be visible before executing the
command again.
These changes are totally compatible with the current acceptance tests.
They just make the tests more robust, but they do not change their
behaviour. In fact, this should minimize some of the sporadic failures
in the acceptance tests caused by their concurrent nature with respect
to the web browser executing the commands.
However, the ElementWrapper is not a silver bullet; it handles the most
common situations, but it does not handle every possible scenario. For
example, the acceptance tests would still fail sporadically if an
element can become staled several times in a row (uncommon) or if it
does not become visible before the timeout expires (which could still
happen in a loaded system even if the components under test work right,
but obviously it is not possible to wait indefinitely for them).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Christoph Wurst
John Molakvoæ (skjnldsv)
Arthur Schiwon