Fails with:
* tests/acceptance/features/app-files.feature:90
<details><summary>Show full log</summary>
```
Scenario: show favorites # /drone/src/github.com/nextcloud/server/tests/acceptance/features/app-files.feature:90
Given I am logged in # LoginPageContext::iAmLoggedIn()
And I mark "welcome.txt" as favorite # FileListContext::iMarkAsFavorite()
When I open the "Favorites" section # AppNavigationContext::iOpenTheSection()
Then I see that the current section is "Favorites" # AppNavigationContext::iSeeThatTheCurrentSectionIs()
Then I see that the file list contains a file named "welcome.txt" # FileListContext::iSeeThatTheFileListContainsAFileNamed()
Row for file welcome.txt in file list could not be found after 100 seconds (NoSuchElementException)
```
</details>
Signed-off-by: Morris Jobke <hey@morrisjobke.de>
To reshare a file there must be at least three enabled users in the
system; although it would be possible to run the steps to create a third
user in the scenarios that need it for convenience a third enabled user
besides "admin" and "user0" was added to the default setup.
In a similar way, a new step was added too to login as a given user
name, similar to the steps to log in as "user0" and as "admin".
Finally, another actor, "Jim", was introduced for those scenarios which
should be played by three standard actors (that is, without a special
configuration like "Rubeus").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, each section of the Files app ("All files", "Favorites"...) had
its own sidebar element. Now there is a single sidebar element for all
the sections in the Files app.
Signed-off-by: John Molakvoæ (skjnldsv) <skjnldsv@protonmail.com>
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>
Morris Jobke
Daniel Calviño Sánchez
Julius Härtl
John Molakvoæ (skjnldsv)