Diagnosing bug 1006075 led me to believe that our mochitest-browser framework instantiates and runs the update-timer service (http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsIUpdateTimerManager.idl, http://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateTimerManager.js).
Just my luck, the fx-team TBPL test runners for Linux/Debug take just the right amount of time to run the test suite, that the update timer service usually invokes the Add-on Manager's background update at the same time as the test suite is trying to test it, leading to unpredictable behaviour. The problem was detected because I put in a sanity check (since backed out) to throw an error if a background update starts while another is in progress. As far as I can tell, very few tests depend on the update manager; there is a small test suite specifically for the update manager, but I don't see anything else that should indirectly depend on having it run. I propose that we disable the update timer manager in at least the mochitest-browser test suite and xpcshell (if it isn't already); I'm open to suggestions for other suites where it is on and shouldn't be. I'm also interested in suggestions for the best way to implement the disable. - irving - _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
