[8.11] [Dashboard] Fix flaky sync_colors.tsx test (#172633) (#172692)

# Backport

This will backport the following commits from `main` to `8.11`:
- [[Dashboard] Fix flaky `sync_colors.tsx` test
(#172633)](https://github.com/elastic/kibana/pull/172633)

<!--- Backport version: 8.9.7 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Hannah
Mudge","email":"Heenawter@users.noreply.github.com"},"sourceCommit":{"committedDate":"2023-12-06T14:55:13Z","message":"[Dashboard]
Fix flaky `sync_colors.tsx` test (#172633)\n\n## Summary\r\n\r\nIt is
possible for the `noDataPopover` to take more than the
`100ms`\r\ntimeout from `ensureHiddenNoDataPopover` (pictured below) to
appear - in\r\nthese cases, any tests that make use of the Lens page
object's\r\n`goToTimeRange` method will fail due to clicking the wrong
element (the\r\ntour step rather than the time
picker).\r\n\r\n\r\n![image](35de1215-6f9f-4a72-a0ab-e1a60f5bb80a)\r\n\r\n\r\nWhile
my initial thought was to simply increase the timeout for
the\r\n`noDataPopover` check, this isn't ideal - **a lot** of tests use
the\r\n`goToTimeRange` method and, by doing this, we would be slowing
down\r\n**every single one of them** even when the test wouldn't have
failed to\r\nbegin with! Instead, I've chosen to surround the important
parts of the\r\ncode in `goToTimeRange` with a `retry` - that way, if
the\r\n`noDataPopover` never shows up or it shows up comfortably within
the\r\n`100ms` timeout, the impact to the speed of a given test will
be\r\n**minimal**; however, if the no data popover shows up **outside**
of\r\nthis timeout, the retry will save the test from outright
failure.\r\n\r\n### [Flaky
Test\r\nRunner](1ac033d7-6cc1-4789-9a2b-6c7b8c34f67c)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"d9e2d06512196ff6800a8441fc4605c258f206dd","branchLabelMapping":{"^v8.12.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Presentation","loe:small","release_note:skip","impact:critical","backport:prev-minor","v8.12.0","v8.13.0"],"number":172633,"url":"https://github.com/elastic/kibana/pull/172633","mergeCommit":{"message":"[Dashboard]
Fix flaky `sync_colors.tsx` test (#172633)\n\n## Summary\r\n\r\nIt is
possible for the `noDataPopover` to take more than the
`100ms`\r\ntimeout from `ensureHiddenNoDataPopover` (pictured below) to
appear - in\r\nthese cases, any tests that make use of the Lens page
object's\r\n`goToTimeRange` method will fail due to clicking the wrong
element (the\r\ntour step rather than the time
picker).\r\n\r\n\r\n![image](35de1215-6f9f-4a72-a0ab-e1a60f5bb80a)\r\n\r\n\r\nWhile
my initial thought was to simply increase the timeout for
the\r\n`noDataPopover` check, this isn't ideal - **a lot** of tests use
the\r\n`goToTimeRange` method and, by doing this, we would be slowing
down\r\n**every single one of them** even when the test wouldn't have
failed to\r\nbegin with! Instead, I've chosen to surround the important
parts of the\r\ncode in `goToTimeRange` with a `retry` - that way, if
the\r\n`noDataPopover` never shows up or it shows up comfortably within
the\r\n`100ms` timeout, the impact to the speed of a given test will
be\r\n**minimal**; however, if the no data popover shows up **outside**
of\r\nthis timeout, the retry will save the test from outright
failure.\r\n\r\n### [Flaky
Test\r\nRunner](1ac033d7-6cc1-4789-9a2b-6c7b8c34f67c)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"d9e2d06512196ff6800a8441fc4605c258f206dd"}},"sourceBranch":"main","suggestedTargetBranches":["8.13"],"targetPullRequestStates":[{"branch":"main","label":"v8.12.0","labelRegex":"^v8.12.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/172633","number":172633,"mergeCommit":{"message":"[Dashboard]
Fix flaky `sync_colors.tsx` test (#172633)\n\n## Summary\r\n\r\nIt is
possible for the `noDataPopover` to take more than the
`100ms`\r\ntimeout from `ensureHiddenNoDataPopover` (pictured below) to
appear - in\r\nthese cases, any tests that make use of the Lens page
object's\r\n`goToTimeRange` method will fail due to clicking the wrong
element (the\r\ntour step rather than the time
picker).\r\n\r\n\r\n![image](35de1215-6f9f-4a72-a0ab-e1a60f5bb80a)\r\n\r\n\r\nWhile
my initial thought was to simply increase the timeout for
the\r\n`noDataPopover` check, this isn't ideal - **a lot** of tests use
the\r\n`goToTimeRange` method and, by doing this, we would be slowing
down\r\n**every single one of them** even when the test wouldn't have
failed to\r\nbegin with! Instead, I've chosen to surround the important
parts of the\r\ncode in `goToTimeRange` with a `retry` - that way, if
the\r\n`noDataPopover` never shows up or it shows up comfortably within
the\r\n`100ms` timeout, the impact to the speed of a given test will
be\r\n**minimal**; however, if the no data popover shows up **outside**
of\r\nthis timeout, the retry will save the test from outright
failure.\r\n\r\n### [Flaky
Test\r\nRunner](1ac033d7-6cc1-4789-9a2b-6c7b8c34f67c)\r\n\r\n\r\n###
Checklist\r\n- [x] [Unit or
functional\r\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\r\nwere
updated or added to match the most common scenarios\r\n\r\n### For
maintainers\r\n\r\n- [ ] This was checked for breaking API changes and
was
[labeled\r\nappropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"d9e2d06512196ff6800a8441fc4605c258f206dd"}},{"branch":"8.13","label":"v8.13.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->

Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>

test/functional/page_objects/time_picker.ts

@@ -57,6 +57,7 @@ export class TimePickerPageObject extends FtrService {
     });
     if (isVisible) {
       await this.testSubjects.click('noDataPopoverDismissButton');
+      await this.testSubjects.waitForDeleted('noDataPopoverDismissButton');
     }
   }
 

x-pack/test/functional/page_objects/lens_page.ts

@@ -66,12 +66,14 @@ export function LensPageProvider({ getService, getPageObjects }: FtrProviderCont
      * a range that has data in our dataset.
      */
     async goToTimeRange(fromTime?: string, toTime?: string) {
-      await PageObjects.timePicker.ensureHiddenNoDataPopover();
-      fromTime = fromTime || PageObjects.timePicker.defaultStartTime;
-      toTime = toTime || PageObjects.timePicker.defaultEndTime;
-      await PageObjects.timePicker.setAbsoluteRange(fromTime, toTime);
-      // give some time for the update button tooltip to close
-      await PageObjects.common.sleep(500);
+      const from = fromTime || PageObjects.timePicker.defaultStartTime;
+      const to = toTime || PageObjects.timePicker.defaultEndTime;
+      await retry.try(async () => {
+        await PageObjects.timePicker.ensureHiddenNoDataPopover();
+        await PageObjects.timePicker.setAbsoluteRange(from, to);
+        // give some time for the update button tooltip to close
+        await PageObjects.common.sleep(500);
+      });
     },
 
     /**