Right now autocomplete sessions are services, one service per type (ldap, addrbook, ...). This has the problem that if there are multiple client windows using a given a type of session, and that session inherits from nsIAutoCompleteSession (eg nsILDAPAutoCompleteSession, nsIAbAutoCompleteSession), and the session has parameters that are initialized once per widget (both LDAP and AddrBook sessions do), the settings of the most-recently initialized window stomp on the settings of windows opened earlier. The most trivial example that can be seen is if you open one compose window with one identity, the addressbook autocomplete will use that first default domain. Open a second window, and set it to a different identity, and now the addressbook autocomplete in both windows uses second default domain. This causes similar problems in LDAP, but more severe, because one of the initialized properties of the LDAP autocomplete session is which server gets used to autocomplete against. Additionally, at some point in the not-too-distant future, LDAP wants to be able to autocomplete against multiple servers in the same window simultaneously. Ducarroz and I talked this over this afternoon, and he came up with the idea of having an autocomplete session service, which would keep specific sessions cached. In the case of mail autocomplete, there would ultimately be at most one session per identity per addressbook plus one session per identity per LDAP server. This means that the sessions would no longer be services, but there wouldn't be new sessions created for every new compose window. Thoughts?

After talking to dmose on irc we've decided that we can solve his problems by allowing sessions to be passed to the widget by reference rather than by their registered name. I'll get on it....

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

*** This bug has been marked as a duplicate of 79792 ***