995533 - Don't sleep for 30s in browser_crash_detection.js

Status: NEW

(Toolkit :: Startup and Profile System, defect)

Description

[Gregory Szorc [:gps]]

As part of investigating bug 995463, I stumbled across browser_crash_detection.js and noticed a hard-coded 35s sleep: https://hg.mozilla.org/mozilla-central/file/6149db60c6cb/toolkit/components/startup/tests/browser/browser_crash_detection.js#l19

That 35s sleep is excessive and only wastes automation resources.

There are two things we can do to make it better:

1) Dynamically lower the wait period based on some other value, such as time since session restore.

2) Make the threshold for startup crash times configurable and trigger earlier during testing (https://hg.mozilla.org/mozilla-central/file/6149db60c6cb/browser/base/content/browser.js#l1173)

1 will help when running the test as part of a larger suite. But if the test executes by itself or earlier in a test run, we may still incur a 30s hang. #2 is a more robust solution. A concern with #2 is it will diminish the accuracy of the test. From what little I can glean about how this feature works, it won't.

Comment 1

[Rob Wu [:robwu]]

In bug 1728461 a regression was identified in the startup cache on Android.

The unit test mentioned here could have caught the issue, but it was browser-specific.

I introduced a new mochitest that also runs on Android to serve as a regression test, but it waits for up to 30 seconds because of the hardcoded 30 second timer.

I'm thinking of adding a Cu.isInAutomation check to lower the timer in test automation - https://phabricator.services.mozilla.com/D125131#4072427