Solve acceptance test failure due to clicks on covered elements

Firefox and Chrome drivers for Selenium refuse to click on an element if
the point to be clicked is covered by a different element, throwing an
UnknownError exception with message "Element is not clickable at point
({x}, {y}). Other element would receive the click: {element}". Although
in general that would be a legit error (as the user would not be able to
click on the element) due to a bad layout, sometimes this can be just a
temporal issue caused by an animation, in which case there would be no
problem once the animation finished and the elements are all in their
final location.

Unfortunately, automatically handling those situations in which the
problem is caused by an animation by just retrying a few times if the
element to be clicked is covered before giving up would probably cause
confusion instead of easing test writing.

The reason is that if the center of the element is covered by another
one the Firefox driver for Selenium tries to click on the corners of the
element instead. The problem is that the coordinates used for the click
are integer values, but Firefox has sub-pixel accuracy, so sometimes
(depending on which corner is not covered and whether the left, top,
width or height properties of the element to be clicked have a decimal
component or not) the clicks silently land on a different HTML element
(and that is with squared borders; with round borders they always land
on a different HTML element. That was partially addressed for Selenium
3.0 by clicking first on the edges, but it would still fail if the
middle point of the edges is covered but not the corners).

It is not possible to fix or even detect all that from the tests (except
maybe with some extreme hacks involving accessing private PHP members
from Mink and bypassing or replacing the standard JavaScript executed by
the Firefox driver with a custom implementation...), so it is not
possible to ensure that clicks during an animation will land on the
right element (in fact it is not possible even on static elements,
although except when the layout is wrong there should be no problem);
sometimes retrying a click when the element is covered would solve the
problem, sometimes it would cause a different element to be clicked (and
sometimes there would be even no retry, as the first click would have
silently landed on a different element than the expected one).

Therefore, a different approach must be used. Instead of trying to
automatically handle clicks during animations the tests must be written
being aware of the problem and thus waiting somehow for the animations
that can cause a problem to end before performing the clicks.

Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>

tests/acceptance/features/app-files.feature

@@ -145,6 +145,14 @@ Feature: app-files
     Given I am logged in
     And I create a new folder named "A name alphabetically lower than welcome.txt"
     And I see that "A name alphabetically lower than welcome.txt" precedes "welcome.txt" in the file list
+    # To mark the file as favorite the file actions menu has to be shown but, as
+    # the details view is opened automatically when the folder is created,
+    # clicking on the menu trigger could fail if it is covered by the details
+    # view due to its opening animation. Instead of ensuring that the animations
+    # of the contents and the details view have both finished it is easier to
+    # close the details view and wait until it is closed before continuing.
+    And I close the details view
+    And I see that the details view is closed
     When I mark "welcome.txt" as favorite
     Then I see that "welcome.txt" is marked as favorite
     And I see that "welcome.txt" precedes "A name alphabetically lower than welcome.txt" in the file list
@@ -153,6 +161,14 @@ Feature: app-files
     Given I am logged in
     And I create a new folder named "A name alphabetically lower than welcome.txt"
     And I see that "A name alphabetically lower than welcome.txt" precedes "welcome.txt" in the file list
+    # To mark the file as favorite the file actions menu has to be shown but, as
+    # the details view is opened automatically when the folder is created,
+    # clicking on the menu trigger could fail if it is covered by the details
+    # view due to its opening animation. Instead of ensuring that the animations
+    # of the contents and the details view have both finished it is easier to
+    # close the details view and wait until it is closed before continuing.
+    And I close the details view
+    And I see that the details view is closed
     And I mark "welcome.txt" as favorite
     And I see that "welcome.txt" is marked as favorite
     And I see that "welcome.txt" precedes "A name alphabetically lower than welcome.txt" in the file list

tests/acceptance/features/bootstrap/FilesAppContext.php

@@ -77,6 +77,15 @@ class FilesAppContext implements Context, ActorAwareInterface {
 				describedAs("Current section details view in Files app");
 	}
 
+	/**
+	 * @return Locator
+	 */
+	public static function closeDetailsViewButton() {
+		return Locator::forThe()->css(".icon-close")->
+				descendantOf(self::currentSectionDetailsView())->
+				describedAs("Close current section details view in Files app");
+	}
+
 	/**
 	 * @return Locator
 	 */
@@ -387,6 +396,13 @@ class FilesAppContext implements Context, ActorAwareInterface {
 		$this->actor->find(self::detailsMenuItem(), 2)->click();
 	}
 
+	/**
+	 * @Given I close the details view
+	 */
+	public function iCloseTheDetailsView() {
+		$this->actor->find(self::closeDetailsViewButton(), 10)->click();
+	}
+
 	/**
 	 * @Given I open the input field for tags in the details view
 	 */