Bring the browser window of an actor to the foreground when acting as him

[danxuliu]

This pull request works around a bug in the Firefox driver of Selenium and/or Firefox itself (I tracked the bug down to Selenium, but I am not sure if it comes from it or even deeper, and unfortunately I do not have time to keep digging ;-) ). However, it does not fix any existing issue with the acceptance tests, but makes them more robust preventing the bug from manifesting in future tests.

Due to the bug, if a window is in the background, it is not possible to set the value of an input field that has a range selected. To set a value in an input field the Selenium extension for Mink sends as many delete and backspace characters as characters are currently in the field (thus clearing it no matter where the cursor is), and then sends the new value. However, when the window is in the background and the input field has a range selected, only the selected range is modified (even if as many delete and backspace characters as characters are in total are sent), so the input field ends having the new value surrounded by the part of the old value that was not in the selected range.

How does this affect the acceptance tests? 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. When acting again as a previous actor his browser window stayed in the background, and here is where the problem appeared. For example, it would not be possible to rename a file in the Files app with a previous actor (although it would work with the most recent one), as when a file is renamed the filename, but not the extension, is selected in the input field.

To work around the problem now when acting again as a previous actor his browser window is brought to the foreground (which also reflects better how a user would interact with the browser in real life).

I would like to backport this to stable14, as it only affects the acceptance tests, it could be needed if some future tests that rely on this (even unknowingly ;-)) are backported to stable14, and it could by needed by some tests in Talk 4.X, which is compatible only with Nextcloud 14.

How to test:

• Add the following method to tests/acceptance/features/bootstrap/LoginPageContext.php (the bug is unrelated to the login page, but it is the easiest place to trigger it):

	/**
	 * @Given I set the value in an input field that has a range selected in its previous value
	 */
	public function iSetTheValueInAnInputFieldThatHasARangeSelectedInItsPreviousValue() {
		$this->featureContext->iVisitTheHomePage();

		$this->actor->find(self::userNameField(), 10)->setValue("1234567890");

		$this->actor->getSession()->executeScript("$('#user').selectRange(0, 2);");

		// Wait a little to ensure that the range was selected before setting
		// the value.
		sleep(5);

		$this->actor->find(self::userNameField())->setValue("abcde");

		PHPUnit_Framework_Assert::assertEquals(
			"abcde", $this->actor->find(self::userNameField())->getValue());
	}

• Add the following scenario to any .feature file, for example, as the first scenario in login.feature:

  Scenario: buggy handling of input fields in background windows
    Given I act as John
    And I act as Jane
    And I act as John
    And I set the value in an input field that has a range selected in its previous value

• Run the scenario from tests/acceptance/ with ./run.sh features/login.feature:3

Without the workaround the test fails with

      Failed asserting that two strings are equal.
      --- Expected
      +++ Actual
      @@ @@
      -'abcde'
      +'abcde34567890'