Did you know that until 2 weeks ago, very many browser-chrome mochitests included 300ms waits?
Whenever `BrowserTestUtils.switchTab` was called (either directly, or indirectly from helpers like `openNewForegroundTab` or `withNewTab`), it waited for a `TabSwitchDone` event which is only dispatched after a 300ms delay controlled by the `browser.tabs.remote.unloadDelayMs` preference.
Consequences of this change include:
- Many browser-chrome mochitests now run much faster locally.
- The average bc job time on CI has decreased by about a minute.
- A few tests became perma-fail, and many low frequency intermittent failures became frequent. To green up the tree, I introduced a “test.wait300msAfterTabSwitch” preference that reverts to the previous behavior, and I had to set this pref in a bit more than 350 tests (that’s about 4.5% of all browser chrome mochitests).
Please avoid setting the “test.wait300msAfterTabSwitch” preference in new tests and instead await the thing the test actually needs. Debugging existing tests in your components to remove the preference would also be useful, but I understand that other tasks are higher priority. Debugging this kind of issue might be a good way to get familiar with using the Firefox Profiler to debug tests failures (
https://firefox-source-docs.mozilla.org/testing/mochitest-plain/index.html#debug-using-the-firefox-profiler ).
-- Florian Quèze