A leftover from Menu's pre-Popover days. Unnecessary given it's now using the Popover API.

Using aTimeout(0) to wait for Floating UI has always bothered me because there's no guarantee that Floating UI takes no more than a tick—especially in CI, which runs weaker hardware.

Since I introduced sub-Menus into Menu, we've seen this inherent issue with aTimeout(0) play out because sub-Menus create additional Floating UI work that, all together, sometimes take more than a tick to complete.

Waiting for the browser to become idle seems like the best way to wait for Floating UI in tests without components having to expose something (for example, a pseudo-private field that's a Promise) specifically for tests to wait on.

Narrator: "He was missing something obvious."

Or at least it appears that way. I've gotten nothing but green builds after switching to requestIdleCallback() (below). I previously switched from await aTimeout(0) to a programmatic click() because I was reluctant to pass an even more arbitrary number to aTimeout().

But, it turns out, click() didn't make these tests less flaky because of something to do with sendMouse()—like I thought. Instead, it made these tests less flaky seemingly because it's synchronous and thus faster than sendMouse().

A programmatic click being faster, combined with the timeout on line 235, gave Floating UI just enough time to recalculate Menu's position—allowing the assertions below to succeed.

I wrote a short story below that'll give you more context.

Green builds:

As a followup, I'll replace uses of aTimeout(0) (at least ones used to wait for Floating UI) throughout the codebase with requestIdleCallback().

Tests that use requestIdleCallback() will be slightly slower, because waiting for the browser to become idle takes longer than a single tick. But our tests should be far less flaky—if they're flaky at all. Or at least that's the idea. Time will tell.