285921 - SMTP server improperly resets to default server when viewing account settings

Status: RESOLVED FIXED

(Thunderbird :: Account Manager, defect)

Description

[Jim Ginn]

I have seen this bug from earlier builds, although I am afraid I do not have a
regression window. My guess is that it is a result of the SMTP UI improvements.
Basically, viewing account settings for an account with a non-default SMTP
server twice will cause the SMTP server to reset to the default server. It also
only effects the currently selected account - all of the other accounts will
retain their servers.

Steps to reproduce:
1. Go to Tools->Account Settings.
2. For the selected account, change the SMTP sever to anything but the default
server. Hit "OK".
3. Go to Tools->Account Settings. Verify that the SMTP server is still correctly
set. Hit "OK".
4. Go to Tools->Account Settings. Notice that the SMTP server has been set to
the default server.

Comment 1

[WADA:World Anti-bad-Duping Agency]

This bug occurs on Mozilla trunk 2005-03-13-04(Win/2K) too.
 (1) Choose an account, then change SMTP choice to specific SMTP
 (2) View "Server Settings" of the account
 (3) View "Account Settings" by clicking account name
     ==> SMTP choice is the specific SMTP
 (4) View "Server Settings" of the account
 (5) View "Account Settings" by clicking account name
     ==> SMTP choice is changed to "Use Deafult Server"

Comment 2

[Scott MacGregor]

you have to be hitting ok to see this.

canceling or hitting escape on the account manager and you won't see the problem.

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> canceling or hitting escape on the account manager and you won't see the problem.
Your are absolutely right.
No problem if "OK" will never be pressed.
But...
We can not press "OK" after viewing account settings any more...

---------------------------------------------------------------------
(0) Say account name is ACCOUNT-1, SMTPs are SMTP-1(default) & SMTP-2
---------------------------------------------------------------------
(1) Change ACCOUNT-1's SMTP choice to SMTP-2, then press "OK"
---------------------------------------------------------------------
(2) View "Account Settings" of ACCOUNT-1
    => SMTP-2 is displayed
(3) Press "OK"
---------------------------------------------------------------------
(4) View "Account Settings" of ACCOUNT-1
    => "Use Default Server" is displayed
---------------------------------------------------------------------

How can user aware on the bug's problem at step(2)?
How can user stop to press "OK" at step (3)?

Possibly problem after fix for Bug 284926.
SMTP server entry's offset or relative position is maybe affected by fix for Bug
284926 which resolved problem of multiple sets of SMTP entries.

Comment 4

[Andrew Schultz]

*** Bug 288349 has been marked as a duplicate of this bug. ***

Comment 5

[Scott MacGregor]

Attachment: the fix

A bit of a stop gap measure. For some reason the smtp menulist (when you don't
change its value) ends up adding an undefined entry in the account manager hash
table. I'm not sure why that is yet. This patch prevents us from saving that
value into prefs when it is undefined.

Comment 6

[r_bugzilla-mozilla-org]

This is still an issue in TB 1.5 (20051201). I have exactly this issue and the only "workaround" is to redifine the default SMTP server to the one I wish to use for this account. When I'm done, I have to switch it back. Real pain in the a$$.

Comment 7

[simon huynh]

I see someone has already noted that the bug persists in ver 1.5 (downloaded 1/20/06).  Same bug as in ver 1: with multiple smtp servers entered, only the one at the top of the list gets acknowledged, regardless of which is selected as default.  The only remedy now seems to empty out the list until the smtp server you wish to use is at the top of the list.

One thing I don't understand: WADA's comments seem to imply that one can select a particular smtp for each incoming email account.  However, the Account Settings navigation bar on the left seems to suggest that all smtp server accounts, which are categorically lumped under "Outgoing Server", have no special relation to the incoming email account. 

Somebody please re-open this bug.
   

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #7)
> One thing I don't understand: WADA's comments seem to imply that one can select
> a particular smtp for each incoming email account.  However, the Account
> Settings navigation bar on the left seems to suggest that all smtp server
> accounts, which are categorically lumped under "Outgoing Server", have no
> special relation to the incoming email account. 

Confusion like you, especially in "SMTP choice" for account/identity, is already resolved by Bug 202468 when Tb 1.5, altough Bug 222388 is still open.
See current account settings panel on Tb 1.5.
Comment #1 is for problem on the panel.

And Enhancement for SMTP definition/choice in accound wizard is already opend.

Search Bugzilla please.
 1) Go https://bugzilla.mozilla.org/query.cgi?format=specifickeyword  
 2) Status: Open, Product: All, Words: SMTP
Only 200 bugs are isted(as of today). You can search additionaly in the listing thru "Find"(CTRL+F). 

Comment 9

[simon huynh]

sorry, please ignore that last comment.  my version of 1.5 seems to be handling this issue fine.  

(In reply to comment #7)
> I see someone has already noted that the bug persists in ver 1.5 (downloaded
> 1/20/06).  Same bug as in ver 1: with multiple smtp servers entered, only the
> one at the top of the list gets acknowledged, regardless of which is selected
> as default.  The only remedy now seems to empty out the list until the smtp
> server you wish to use is at the top of the list.
> 
> One thing I don't understand: WADA's comments seem to imply that one can select
> a particular smtp for each incoming email account.  However, the Account
> Settings navigation bar on the left seems to suggest that all smtp server
> accounts, which are categorically lumped under "Outgoing Server", have no
> special relation to the incoming email account. 
> 
> Somebody please re-open this bug.
> 
>