Bug 93453's patch introduced a pref to control whether autocompletion will append "@domain.tld" (from the identity) to an otherwise unknown address string. This is not working as expected. Steps to reproduce: 1) Configure with: mail.identity.default.autocompletToMyDomain = false mail.identity.idX.autocompletToMyDomain = true 2) Restart TB (I'm not sure if this is required) 3) Select an account that defaults to an identity other than idX; select New Message. 4) In the address field, type "abc" (or some other string that doesn't appear in your address book). 5) Observe: no autocompletion 6) Clear the address field 7) Switch the identity in this window to idX 8) In the address field, type "abc" again; observe 9) Clear the address field 10) Switch the identity in this window back to the original 11) In the address field, type "abc" again; observe 12) Without closing the current address, open another compose window with the same original identity (not idX) 13) In the address field, type "abc" again; observe Actual results: (8), (11) and (13) all complete with idX's domain.tld Expected results: (8) autocomplete with idX's domain.tld (11) and (13) do not autocomplete at all TB 1.5, Win2K; also seen TB 1.6a1-0203.
Just to say that this works as it should do on SM trunk BuildID 2006020609, so probably frontend rather than backend issue.
That's interesting information. I wonder if we just missed a patch in the thunderbird front end when this landed on the 1.8 branch for Thunderbird 1.5? oh never mind, I see mcow says this is in the trunk and the branch for Thunderbird.
Created attachment 211094 [details] [diff] [review] possible fix I haven't tested this yet, but this patch adds some additional changes from Ian's seamonkey port of David's fix back into Thunderbird. It might make a difference.
Bear in mind the two situations of a corporate user at her office & at home. At the office, almost *all* messages will be to local logins and aliases. These have no need for auto-append (which doesn't work on replies or multiple addresses on the same line anyway) since the MTA will handle that for the MUA. The result will always be a fully qualified domain name (FQDN) performed by the MTA (which also performs the check for a valid match). Luckily, the extension to bug #312818 allows TB 1.5 users to again send email within a corporate domain WITH OR WITHOUT autocomplete like they were able to in TB 1.0.7. Note again this has *nothing* per se to do with autocomplete. It has only to do with allowing unqualified domain names to be passed to the MTA on the local intranet server. The situation changes at home. This same user may be on domain "pacbell.net" but they wish to send all their emails to domain "mycompany.com". Eudora 5.x allows this for example. If a different domain than the default domain is set, then (and only then) this different domain is silently (or not) appended to all outgoing unqualified addresses. By allowing the MTA to pass unqualified addresses and by allowing the option to (silently or not) append a designated domain to unqualified addresses, efficiency in today's corporate work environment is attained.
I've landed this patch on the 1.8 branch and the trunk. You should be able to test this out with the 02/28 builds Mike.
That seems to have done the trick -- I checked with the 1.6a1-0228 build and it's working as expected. It even works as expected if you dynamically change the identity within the same window.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird2.0
Comment on attachment 211094 [details] [diff] [review] possible fix we're gonna fix this regression in 18.104.22.168 as well. Many thanks to Iann who pointed out that this worked in the suite. That made it a lot easier for me find out what was missing :).
Attachment #211094 - Flags: approval22.214.171.124+
we're past the 126.96.36.199 point on the 1.8.0 branch; whatever the particular product will be called we're in the "fixed188.8.131.52" branch range.
Keywords: fixed184.108.40.206 → fixed220.127.116.11
V with TB 18.104.22.168, 2a1-0416, 3a1-0426, Win2K.
Status: RESOLVED → VERIFIED
*** Bug 337754 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.