`webUIMoveFilesFolders/moveFiles.feature:51` failed on nightly builds in OC10

[sushmita56]

The following scenario failed in nightly build and needs further investigation

Scenario: Move multiple files at once # features/webUIMoveFilesFolders/moveFiles.feature:51
- Connecting to selenium on port 4444...

ℹ Connected to selenium on port 4444 (417ms).
  Using: chrome (94.0.4606.61) on Linux platform.

    Given user "Alice" has been created with default attributes and without skeleton files in the server
    And user "Alice" has created folder "simple-folder" in the server
    And user "Alice" has uploaded file "lorem.txt" to "lorem.txt" in the server
    Given user "Alice" has logged in using the webUI
√ Element <#user> was visible after 1121 milliseconds.
√ Element <#user> was not present after 45 milliseconds.
√ Element <#files-view> was visible after 1129 milliseconds.
√ Element <//*[self::table[contains(@class, "files-table")] or self::div[contains(@class, "files-empty")] or self::div[contains(@class, "files-not-found")]]> was visible after 181 milliseconds.
    And user "Alice" has uploaded file "data.zip" to "data.zip" in the server
    And user "Alice" has uploaded file "data.zip" to "testapp.zip" in the server
    And the user has reloaded the current page of the webUI
    When the user batch moves these files into folder "simple-folder" using the webUI
      │ file_name   │
      │ data.zip    │
      │ lorem.txt   │
      │ testapp.zip │
√ Element <//span[contains(@class, "oc-resource-name") and (@data-test-resource-name='data.zip' or @data-test-resource-path='/data.zip')]/ancestor::tr[contains(@class, "oc-tbody-tr")]> was visible after 38 milliseconds.
√ Element <//span[contains(@class, "oc-resource-name") and (@data-test-resource-name='lorem.txt' or @data-test-resource-path='/lorem.txt')]/ancestor::tr[contains(@class, "oc-tbody-tr")]> was visible after 43 milliseconds.
√ Element <//span[contains(@class, "oc-resource-name") and (@data-test-resource-name='testapp.zip' or @data-test-resource-path='/testapp.zip')]/ancestor::tr[contains(@class, "oc-tbody-tr")]> was visible after 40 milliseconds.
√ Element <//span[contains(@class, "oc-resource-name") and (@data-test-resource-name='simple-folder' or @data-test-resource-path='/simple-folder')]/ancestor::tr[contains(@class, "oc-tbody-tr")]> was visible after 40 milliseconds.
√ Element <//*[self::table[contains(@class, "files-table")] or self::div[contains(@class, "files-empty")] or self::div[contains(@class, "files-not-found")]]> was visible after 107 milliseconds.
√ Element <button#location-picker-btn-confirm> was visible after 42 milliseconds.
Timed out while waiting for element <button#location-picker-btn-confirm> to be removed for 200 milliseconds. - expected "not found" but got: "found" (205ms)
Timed out while waiting for element <button#location-picker-btn-confirm> to be removed for 200 milliseconds. - expected "not found" but got: "found" (205ms)
    at Proxy.selectFolderAndConfirm (/var/www/owncloud/web/tests/acceptance/pageObjects/locationPicker.js:12:20)
    at Proxy.moveMultipleResources (/var/www/owncloud/web/tests/acceptance/pageObjects/personalPage.js:257:14) {
  showDiff: false,
  name: 'NightwatchAssertError',
  abortOnFailure: true
}
undefined    ✖ failed
      Error: ElementPresentError
          at Proxy.selectFolderAndConfirm (/var/www/owncloud/web/tests/acceptance/pageObjects/locationPicker.js:18:15)
          at runMicrotasks (<anonymous>)
          at processTicksAndRejections (internal/process/task_queues.js:95:5)
          at Proxy.moveMultipleResources (/var/www/owncloud/web/tests/acceptance/pageObjects/personalPage.js:257:14)
    Then breadcrumb for folder "simple-folder" should be displayed on the webUI
    - skipped
    And the following files should be listed on the webUI
      │ file_name   │
      │ data.zip    │
      │ lorem.txt   │
      │ testapp.zip │
    - skipped

  Result: FAILED

[sushmita56]

Not reproducible locally.

[grgprarup]

The issue is not seen on nightly builds for a long time and cannot reproduce locally with multiple runs. So closing this issue.