On the production tinderboxes (mini-03 to mini-09) we are currently seeing the following test failure when running mozmill tests: TEST-UNEXPECTED-FAIL | test_mail_account_setup EXCEPTION: timeout exceeded for waitForEval('subject._currentConfigFilledIn != null') at: controller.js line 498 Error("timeout exceeded for waitForEval('subject._currentConfigFilledIn != null')") 0 controller.js 498 test_mail_account_setup() test-mail-account-setup-wizard.js 136 frame.js 468 frame.js 520 frame.js 562 frame.js 411 frame.js 568 server.js 164 server.js 168 I've just noticed this is happening on both comm-central *and* comm-1.9.2. comm-1.9.1 doesn't have this test. Interestingly, mini-01 and mini-02 running on the staging tinderboxes are not showing this failure, and it is *very* hard to reproduce (i.e. you have to manually intervene to get the test to fail). For comm-1.9.2, Tinderbox shows a regression range of around 2010/06/15 02:49:53 to 2010/06/15 10:18:36. There were *no* code changes during this time on the comm-1.9.2 branch, and in fact the last relevant comm-1.9.2 change would have been around 2010/06/08. Therefore I'm declaring this is a builder issue, though I expect gozer will need ideas of where to look.

Obvious ideas of things to check: - If the builders can dns lookup, and maybe ping the ispdb (I very much doubt this is the issue). - If the builders can open ports, I think around the 43300 area. This is for a http connection from mozmill to Thunderbird.

So, this patch should help in two ways. 1) It will tell us whether the input fields are populated or not (which could indicate a focus problem, or some other problem), and 2) if it is a focus problem, it will let us fail immediately, instead of waiting the eight seconds for the eval string to timeout. Later, Blake.

(In reply to comment #1) > - If the builders can dns lookup, and maybe ping the ispdb (I very much doubt > this is the issue). > - If the builders can open ports, I think around the 43300 area. This is for a > http connection from mozmill to Thunderbird. We add a MozMill http resource, which points to <http://localhost:4545/autoconfig>, and set that as the url Thunderbird should hit, and it _should_ contain the config file for example.com, so we shouldn't be hitting the ispdb/autoconfig server, but we do need to hit ourselves on port 4545. (I'm now going to make sure that we actually load that file without errors.) Later, Blake.

Yeah, it looks like it works from here. (I added 'pref.setCharPref("mail.wizard.logging.dump", "All");' after 'pref.setCharPref(pref_name, url);', and the output looked like the file got loaded and parsed correctly.

(In reply to comment #1) > Obvious ideas of things to check: > > - If the builders can do dns lookup, and maybe ping the ispdb (I very much doubt > this is the issue). No problem there, but apart from ispdb.mozillamessaging.com, what else would they be resolving ? (and generally, why does such a test even needs DNS resolution?) > - If the builders can open ports, I think around the 43300 area. This is for a > http connection from mozmill to Thunderbird. I don't why they wouldn't be able to do that, and nothing changed on these builders, so if they were able to before, they should still be able to.

Turns out the minis were configured with a first nameserver that didn't respond, adding an additional 2second delay to dns queries. Fixed.

(In reply to comment #5) > (In reply to comment #1) > > Obvious ideas of things to check: > > - If the builders can do dns lookup, and maybe ping the ispdb (I very much doubt > > this is the issue). > No problem there, but apart from ispdb.mozillamessaging.com, what else would > they be resolving ? (and generally, why does such a test even needs DNS > resolution?) Just for posterity, the autoconfig hits http://autoconfig.<domain>/something.xml before hitting the ispdb, which is why it needs DNS resolution. We set it to example.com, to avoid getting any actual hosts. And we set the ispdb url to the MozMill collector so that we don't even hit the actual ispdb. Later, Blake.