881694 - Namespace text fields are not properly cleared when opened for multiple accounts

Status: RESOLVED FIXED

(MailNews Core :: Account Manager, defect)

Description

[Gunnar Frenzel]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36

Steps to reproduce:

I have four IMAP Accounts configured (with different settings for "IMAP-Server-Folder" and IMAP-Server Namespaces (Extras -> Account Settings -> Server Settings (for a IMAP account) -> Advanced). Two of those IMAP accounts have different Namespaces and IMAP-Server-Folders configured, the other two no values set.
I'm using the German language version of Thunderbird so I'm not 100% sure of some dialog names.

Version 17.0.6 of Thunderbird has been used.



Actual results:

1. Opening Account Settings dialog
2. Open Server Settings dialog of an IMAP account with no namespaces and IMAP Server Folder specified and open its Advanced settings subdialog.
-> Fields are empty (correct)
3. Open Server Settings dialog of an IMAP account with namespaces and IMAP Server Folder specified and open its Advanced settings subdialog
-> Fields are filled with the corresponding data (correct)
4. Open the same Advanced settings subdialog as in step 2. and now the fields formerly empty show the values of the server from step 3 (incorrect)

The problem also occurs when some fields of the server in step 2 are filled. All empty fields show the old data from the previously opened dialog.

When closing not just the Advanced Settings subdialog but also the Account Settings dialog and reopen it from the Menu bar the data of the IMAP Server with empty fields are empty again. So they haven't been changed in step 2 or 3, but just displayed wrong in step 4.


Expected results:

In step 4 the correct configuration for the corresponding IMAP Server should be shown (in this case empty fields).

Comment 1

[Gunnar Frenzel]

Attachment: The affected dialog window and text fields

This is the dialog I'm talking about to make sure I didn't get the naming wrong as I'm using the German language version of Thunderbird.

Comment 2

[David Lechner (:dlech)]

Confirmed in daily build (TB24) on Windows and Linux.

Although steps were a little different. 

1. Have 3 IMAP accounts. 1 does not have namespace, 2 has namespace, 3 does not have namespace as described above.
2. Open Account Settings by right-clicking on account 1 in folder tree.
3. Open Advanced Settings for account 1. No namespace - correct.
4. Open Advanced Settings for account 2. Has namespaces - correct.
5. Open Advanced Settings for account 3. Has namespaces (from account 2) - incorrect.
6. Open Advanced Settings for account 1. No namespace - correct (this is different from original poster)

Comment 3

[:aceman]

Attachment: patch

Can you try this?

Comment 4

[David Lechner (:dlech)]

Comment on attachment 761769 [details] [diff] [review]
patch

Review of attachment 761769 [details] [diff] [review]:
-----------------------------------------------------------------

Tested and it works. Removed the patch and the problem came back.

Comment 5

[:aceman]

Comment on attachment 761769 [details] [diff] [review]
patch

Thanks.

Comment 6

[[e-mail]]

Ah, I see now how to reproduce the bug; I wasn't being careful enough, you have to visit the server settings for the account with namespaces before visiting the server settings the the account without namespaces.

Comment 7

[[e-mail]]

Comment on attachment 761769 [details] [diff] [review]
patch

So, this function makes very little sense, unfortunately it was written like this in 1999 and just monkeypatched every time.

* The defaultValue and defaultChecked properties have never existed.
  (The author may have been thinking of HTML input elements.)
* null compares == to undefined so there is no point comparing twice.
* Nobody passes undefined these days anyway.
* The function gets called for some radio buttons even though it also gets
  called for the radiogroup that chooses the value. The code here fortuitously
  avoids changing the radio's value in this case.

So I would really appreciate it if someone was to clean the code up.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/6d0fe5c39609

Comment 9

[:aceman]

Comment on attachment 761769 [details] [diff] [review]
patch

[Approval Request Comment]
Regression caused by (bug #): unknown
User impact if declined: possibly corrupted user settings for the mentioned fields in AM.
Testing completed (on c-c, etc.): TB25
Risk to taking this patch (and alternatives if risky): possible breakage of other fields in the AM.

Comment 10

[Mark Banner (:standard8)]

https://hg.mozilla.org/releases/comm-aurora/rev/8cbbd1ca0876