Each time a new actor appears in a scenario the browser window of the
new actor is put in front of the browser windows of the previous actors.
Before, when acting again as a previous actor his browser window stayed
in the background; in most cases everything worked fine even if the
window was in the background, but due to a bug in the Firefox driver of
Selenium and/or maybe in Firefox itself when the window was in the
background it was not possible to set the value of an input field that
had a range selected.
Now, when acting again as a previous actor his browser window is brought
to the foreground. This prevents the bug from manifesting, but also
reflects better how a user would interact with the browser in real life.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This will make it possible to act propely on moves of future files if we
need to know the size (like for max size virus scanning).
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
As discussed in https://github.com/nextcloud/server/issues/11594 when discovering if
x-forwarded-for is working properly its not possible to use getRemoteAddr because
the "client ip" is returned. For this check the ip of the last hop would be required.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
A revert triggers a move in the DAV client, and the DAV client expects a
DAV error message to be provided by the server in case of failure; if
no error message is given the client ends trying to get an attribute
from an undefined object and "crashes".
Besides that, if the revert fails the "done" callback of the promise
(the first parameter of "then") is never called, so a "fail" callback
should be used instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In Jasmine 2.5 the "it" function takes an optional parameter that should
be called when the async work is completed (returning a promise was
introduced in Jasmine 2.7, so it is not supported yet in the tests). If
the parameter is not declared then the next test is executed without
waiting for the asynchronous work in the previous one to finish, which
could cause that asynchronous work to finish while a different test is
being run.
Note that if that happens the test could still work as expected if it
relied only in local variables. However, in the case of the successful
revert tests, the stubs being checked are not the ones created when that
test was initialized, but the ones created when the next test, the
failed revert test, was initialized and the previous variables were
replaced (although the model itself calls the proper stubs, as they are
set through parameters in function calls).
Besides all that, the checks in the failed revert test were never
executed due to a different problem which will be fixed in the next
commit.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Bjoern Schiessle
Nextcloud bot
trendzetter
blizzz
Stefan Weil
Morris Jobke
Daniel Calviño Sánchez
Roeland Jago Douma
Daniel Kesselberg
Jan-Christoph Borchardt
dependabot[bot]
Julius Härtl
Roeland Jago Douma
Claas Augner