We were getting a few issues with random oranges on the account wizard before, but since the latest changes, we're getting slightly different ones: TEST-PASS | test_remember_password TEST-UNEXPECTED-FAIL | test-retest-config.js | test_re_test_config EXCEPTION: timeout exceeded for waitForEval('subject.disabled == false && subject.hidden == false') at: controller.js line 499 controller.js 499 test-retest-config.js 87 frame.js 469 WindowWatcher_notify([object XPCWrappedNative_NoHelper]) test-window-helpers.js 255 TEST-UNEXPECTED-FAIL | (runtestlist.py) | Exited with code 1 during directory run
This wins the first mozmill failure that shows up in the Thunderbird tree on mozmill for arbpl award: http://arbpl.visophyte.org/?tree=Thunderbird&pushid=5603&log=19178%3A1299790976.1299791885.27652.gz
And this is totally the same thing as my complaint from bug 568153 comment 51: hey, so I just got an intermittent orange on test_re_test_config in test-retest-config.js, the test added for this bug... I could not help but notice that the e-mail address used for the test is "email@example.com", that we then actually do a bunch of DNS lookups against yahoo.com, and even try and talk to the POP server. (It took my local run 30 seconds to get a RST response to my SYN packets...*). This probably explains why the test has a 100second timeout for the first step and 20 second timeouts for the following tests. Can we back this test out entirely in preparation for the next phase of autoconfig stuff? If not, can we make it locally standalone (it looks like test-mail-account-setup-wizard.js might operate along those lines), or failing that, point at MoMo-hosted test servers? * Should I have gotten an actual response? Is it possible that MoMo YVR's IP is blacklisted by Yahoo's pop server because our mac minis are poking it all day long with bogus logins?
Related to bug 604356? Seems like making the accesses purely local will fix both that and this. I mentioned a few possible solutions there.
Andrew, I've added a parameter to wait_for_modal_dialog that allows the user to pass a custom timeout value. That custom value is, in that very test, 30000. But your (awesome) failure breakdown gives 400-ish + 8400-ish ms. of waiting before the timeout... (grey text near the bottom of the link you point to in comment #1).
Created attachment 521782 [details] [diff] [review] Proposed fix Lets try this. Change the domain to "momo.invalid", and provide it via the local http server. This should mean virtually no external lookups, and hopefully an always green test.
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Attachment #521782 - Flags: review?(bugmail)
Attachment #521782 - Flags: review?(bugmail) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
OS: Mac OS X → All
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.3a4
You need to log in before you can comment on or make changes to this bug.