Consider lowering BrowserTestUtils.waitForMutationCondition's default timeout
Categories
(Testing :: Mochitest, task)
Tracking
(Not tracked)
People
(Reporter: dao, Unassigned)
References
Details
Bug 2062448 gave waitForMutationCondition a default timeout of 10 seconds, chosen from try runs at 60s, 30s, 20s and 10s across opt, debug, asan and tsan.
TestUtils.waitForCondition has effectively had a ~5s bound all along (interval = 100, maxTries = 50) and that has been tolerable tree-wide, which suggests 10s may be more generous than it needs to be. A lower default would let a stuck wait name itself sooner and leave more of the task budget for the rest of the test.
This needs testing carefully against today's callers first. Mutation waits were unbounded until bug 2062448. 10s had turned up only one test that needed a higher bound, so there's a real chance we can go lower.
|
Reporter | |
Comment 1•26 days ago
|
||
Measured this. Instrumented waitForMutationCondition to dump every wait that took 500ms or more, set the default to 5s, and pushed browser-chrome across linux opt/debug/asan/tsan plus win11 debug, then harvested all 181 job logs: 327 waits over 500ms, of which 269 finished within 1s and 46 within 2s.
The premise doesn't hold. Two results argue against going lower:
The 4-5s cluster is a single wait, and it isn't machine speed. dom/events/test/clipboard/head.js:94 waits for the paste button to enable, and browser_navigator_clipboard_clickjacking.js deliberately sets that budget to security.dialog_enable_delay * 3, spending it on keypresses to prove the enabling is postponed. It lands at 4054ms on opt, 4091 asan, 4096 debug, 4127 tsan - a flat ~4.1s floor on every platform, opt included. A 5s default would leave that under 1s of margin tree-wide.
Two waits already exceed 5s: waitForPanelClosed in the Screenshots tests, at 5061ms on linux debug and 5133ms on tsan. Filed separately.
That also rules out the more principled version of the idea. runtests.py already scales the per-test timeout by build type (45s opt, 90s asan/debug, 120s tsan) and publishes it as testing.browserTestHarness.timeout, so a bound of harnessTimeout / 9 would have given 5s opt / 10s asan+debug / 13.3s tsan. But the dominant tail is platform-independent - opt is as slow as tsan here - so scaling by build type would tighten precisely where the requirement is unchanged.
With a ~4.1s floor tree-wide, the tightest defensible flat bound is around 8s, and buying 2s of a 45s per-test budget isn't worth a new class of intermittent. 10s is 2.4x the floor. Leaving it.
Description
•