Intermittent test "Tooltip should render the information severity when selected and render the corresponding icon when true"

[rajsite]

🐛 Bug Report

Saw error in a build on main:

Firefox 108.0 (Linux x86_64): Executed 1940 of 1950 (1 FAILED) (skipped 10) (30.739 secs / 25.882 secs)
TOTAL: 1 FAILED, 1939 SUCCESS


1) should render the information severity when selected and render the corresponding icon when true
     Tooltip
     Error: Value of display was unexpectedly empty in /tmp/_karma_webpack_676330/commons.js (line 47927)
isIconVisible@/tmp/_karma_webpack_676330/commons.js:47927:19
@/tmp/_karma_webpack_676330/commons.js:48045:16

💻 Repro or Code Sample

🤔 Expected Behavior

😯 Current Behavior

💁 Possible Solution

🔦 Context

🌍 Your Environment

• OS & Device: [e.g. MacOS, iOS, Windows, Linux] on [iPhone 7, PC]
• Browser [e.g. Microsoft Edge, Google Chrome, Apple Safari, Mozilla FireFox]
• Version [e.g. 1.8.0]

[rajsite]

Related, should render the default state when selected is failing in firefox:

Firefox 108.0 (Linux x86_64) Tooltip should render the default state when selected FAILED
	Error: Value of display was unexpectedly empty in /tmp/_karma_webpack_476548/commons.js (line 48169)
	isIconVisible@/tmp/_karma_webpack_476548/commons.js:48169:19
	@/tmp/_karma_webpack_476548/commons.js:48240:16
    ✗ should render the default state when selected

https://github.com/ni/nimble/actions/runs/4661440580/jobs/8250719307?pr=1177#step:16:3923

[m-akinc]

It looks like any of the tests that call waitForIconVisibilityCheck() can fail this way. All that function does is call waitForUpdatesAsync() twice. I used to get this error consistently on Firefox until I added that second waitForUpdatesAsync().

I replicated one of these tests 3000 times and ran it a few times. It failed between 2-6 times per run (~0.1% failure rate). I then added a third waitForUpdatesAsync() call to waitForIconVisibilityCheck() and tried again. Couldn't get it to fail anymore. I kind of hate this solution, but it seems to address the problem somehow.

[rajsite]

@m-akinc

but it seems to address the problem somehow

I disagree that it addresses the problem. We need a more robust solution then waiting 16ms * some random value (effectively what multiple waits is doing). I'm disabling the test in #1180 to get main stable and put it with the rest of the failing firefox tests. But feel free to investigate further