476044 - Adding a new identity doesn't update the list of "Identities for my account" dialogue immediately, can mislead user into creating duplicate identities

Status: RESOLVED DUPLICATE of bug 768779

(Thunderbird :: Account Manager, defect)

Description

[Dave Townsend [:mossop]]

I clicked the Manage Identities button and it showed me a dialog with my one identity. I then click on Add, set the settings and clicked Ok. The dialog came back still showing one identity. I clicked ok to that and then clicked Manage Identities again and it now showed both.

Comment 1

[Thomas D. (:thomas8)]

Confirmed as a regression for current trunk (14.0a1, 2012-03-28), seen on Windows XP:

STR

1 Tools > Account Settings
2 From "Account Settings - Your account" overview, click "Manage Identities..."
3 From "Identities for Your account" dialogue, click "Add..."
4 From "Identity Settings", fill in Name and Email, then "OK" to create new identity
5 Try to find your new identity on the "Identities for Your account" list
6 Close "Identities for Your account", and "Manage identities" again

Actual reslut

5) The new identity is not immediately added to the "Identities for Your account" list (ux-userfeedback, ux-mode-error)
-> user will think something went wrong and try to create the same new identity again, resulting in duplicate identities (ux-errorprevention)
6) after closing and reopening "Manage identities", the new identity (and its erratic duplicates) are correctly showing up

Expected result

- After confirming identity creation with "OK", the new identity needs to be added *immediately* the the existing list of "Identities for Your account".

Regression Range (regressionwindow-wanted!):

This works correctly on TB 11 release channel:
Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

This is broken on current Daily:
Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120328 Thunderbird/14.0a1

Comment 2

[Thomas D. (:thomas8)]

Given the original report from 2009 for MAC, we have regressed this more than once or somehow differently on different OS.

Comment 3

[Jens Müller (:tessarakt)]

Bug confirmed for Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120601 Thunderbird/14.0a2,
and for a recent Linux Earlybird.

Comment 4

[Thomas D. (:thomas8)]

Aceman is doing some related work in:
Bug 314806 - No function to set default identity

There is a function called refreshIdentityList(aSelectIndex), as seen and modified in his patch of attachment 649356 [details] [diff] [review]. Perhaps adding a single line with a call to that function somewhere at the end of "adding a new identity" could fix this, too, which could also select the newly added identity.

Comment 5

[:aceman]

Can you see if this is the same as bug 768779? :)
Can you see if you get the error message mentioned there and if it is fixed in TB15/16? In current trunk adding identities refreshes fine for me.

Comment 6

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #5)
> Can you see if this is the same as bug 768779? :)

*blush* I think bug 768779 is the one and only TB bug which I haven't looked at yet... ;) Bug 768779 was filed as a perfect duplicate of this bug...

> Can you see if you get the error message mentioned there and if it is fixed
> in TB15/16? In current trunk adding identities refreshes fine for me.

Nice surprise - Bug 768779 was filed & fixed by ...drums.... ACEMAN! :)
Better still: status-thunderbird14: fixed! And so it is (verified)...

I think with guys like aceman, there's hope for TB...!
One day we'll find that all of the 2000+ unconfirmed TB/mailnews bugs [1] are really just duplicates of bugs that the acemans among us have secretly fixed... ;)

Thanks!

[1] https://bugzilla.mozilla.org/buglist.cgi?quicksearch=%3Athun%2Cmail%20status%3Aunconfirmed%20-severity%3Aenh;list_id=3951813

Comment 7

[:aceman]

Actually it is my bad, I should have looked for dupes before filing 768779:) But I assumed it was caused by bug 451728 which I fixed only recently, so it should not have been related to this bug 476044. Maybe that was only partially true and the bug appeared also in the past (maybe due to similar code changes as in bug 768779).