Failing test: Firefox UI Functional Tests.test/functional/apps/visualize/_tsvb_chart·ts - visualize app visual builder switch index patterns should be able to switch between index patterns

[kibanamachine]

A test failed on a tracked branch

Error: retry.try timeout: TimeoutError: Waiting for element to be located By(css selector, .euiFilterSelectItem)
Wait timed out after 10106ms
    at /dev/shm/workspace/kibana/node_modules/selenium-webdriver/lib/webdriver.js:842:17
    at process._tickCallback (internal/process/next_tick.js:68:7)
    at onFailure (test/common/services/retry/retry_for_success.ts:28:9)
    at retryForSuccess (test/common/services/retry/retry_for_success.ts:68:13)

First failure: Jenkins Build

[elasticmachine]

Pinging @elastic/kibana-test-triage (failed-test)

[spalger]

First failure out of PRs, but has failed 13 times in PRs in the last week

Skipped

master: 7787d1e
7.x/7.10: 8566491
7.9: c657cdb

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[dej611]

I managed to reproduce this issue semi-consistently on my local machine with the following setup:

• Force a retry for the setAbsoluteRange action:

   await retry.try(async () => {
     await PageObjects.timePicker.setAbsoluteRange(fromTime, toTime);
   });

  Without this retry the EUI time picker does not behave correctly for some reason
• make the runner start with the Firefox configuration
• once the automated Firefox instance starts, move it beneath another application window so that it will be completely covered by it
  • every other run the bug appears

What I tried so far:

• Force a retry of the combobox action

   await retry.try(async () => {
     await PageObjects.visualBuilder.selectIndexPatternTimeField('timestamp');
   });

  Note that the selectIndexPatternTimeField already has a retry internally, so here it's really just forcing it even more
• Force a wait (500 and 2000 ms) before the test:

   before(async () => {
   	await PageObjects.common.sleep(2000);
   });

  Surprisingly this kicks in a strange behaviour in the EUI combobox where the dropdown is rendered in the wrong position, leading to an occlusion:

   ElementClickInterceptedError: Element <button id="i7cccf750-c814-11ea-be31-25ee38153d22__option-1" class="euiFilterSelectItem" type="button"> is not clickable at point (201,40) because another element <nav class="euiBreadcrumbs euiHeaderBreadcrumbs euiBreadcrumbs--truncate"> obscures it
  

• Force a wait (500 and 2000 ms) before the combobox action leads to the same result as wait before the test

Some notes before explaining the attempts made:

• In Chrome the bug cannot be reproduced - either regular or headless mode
• In Firefox the bug cannot be reproduced when the window is in the front or when in headless mode
• Shadowing the window as explained above showed other similar issues with other tests of the TSVB suite, still related to the EUI combobox dropdown.
• The setup above works with the suite isolated from the rest of the group or even when all group is executed.

Why shadowing the browser window works to reproduce the bug?

I can only make assumptions here, but I guess the windows shadowing leads to a lazy rendering which may simulate some sort of simulation of a slow environment.

[kibanamachine]

New failure: Jenkins Build

[kibanamachine]

New failure: Jenkins Build

[kibanamachine]

New failure: Jenkins Build

[kibanamachine]

New failure: Jenkins Build

[kibanamachine]

New failure: Jenkins Build

[kibanamachine]

New failure: Jenkins Build

[spalger]

Opened backport of fix to 7.9 #78098

[flash1293]

Thanks for taking care of that @spalger Can we close the issue?