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).
Created attachment 760899 [details] 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.
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)
Created attachment 761769 [details] [diff] [review] patch Can you try this?
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 on attachment 761769 [details] [diff] [review] patch Thanks.
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 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 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.