Created attachment 395803 [details] [diff] [review] The fix STR: 1) With a configuration that isn't in the database (e.g. my standard8.plus.com one), go through the normal procedure and it fails (expected). 2) Enter invalid hostnames for both servers (e.g. use .com instead of .net which is something I frequently get wrong). 3) Re-test account config - which then fails. 4) Enter correct hostnames for both servers - this succeeds 5) Select finish and go to the insecure notice. Actual Result: The insecure notice has server details such as "-1:143" Expected Result: The hostname and port. The best I've worked this out is that we're storing the errors in incomingEx and outgoingEx within guessConfig. I think we hit incomingError at step 3 which sets incomingEx. Then we enter the correct details, and we get into incomingSuccess - which calls checkDone(). However incomingEx is still set, so the failure routine gets called rather than the success one. So I think the fix is to null out incomingEx/outgoingEx in their respective success functions and assume that these aren't called in failure cases.
Oh btw I've seen this before and found it whilst I was re-investigating the blocker bug 490139.
Comment on attachment 395803 [details] [diff] [review] The fix this looks reasonable, though I haven't tried running with the patch.
Attachment #395803 - Flags: superreview?(bienvenu) → superreview+
Attachment #395803 - Flags: review?(philringnalda) → review+
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.