326280 - Suppression of append-domain autocompletion not working

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Mike Cowperthwaite]

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.

Comment 1

[Ian Neal]

Just to say that this works as it should do on SM trunk BuildID 2006020609, so probably frontend rather than backend issue.

Comment 2

[Scott MacGregor]

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.

Comment 3

[Scott MacGregor]

Attachment: 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.

Comment 4

[Cindy Schott]

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. 

Comment 5

[Scott MacGregor]

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.

Comment 6

[Mike Cowperthwaite]

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.

Comment 7

[Scott MacGregor]

awesome.

Comment 8

[Scott MacGregor]

Comment on attachment 211094 [details] [diff] [review]
possible fix

we're gonna fix this regression in 1.5.0.2 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 :).

Comment 9

[Daniel Veditz [:dveditz]]

we're past the 1.8.0.1 point on the 1.8.0 branch; whatever the particular product will be called we're in the "fixed1.8.0.2" branch range.

Comment 10

[Mike Cowperthwaite]

V with TB 1.5.0.2, 2a1-0416, 3a1-0426, Win2K.

Comment 11

[Jo Hermans]

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