Closed Bug 93453 Opened 23 years ago Closed 19 years ago

email autocomplete always adds "@localdomain" to addresses


(MailNews Core :: Composition, defect)

Not set


(Not tracked)



(Reporter: mitch, Assigned: Bienvenu)




(1 file, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2)
Gecko/20010726 Netscape6/6.1
BuildID:    Netscape 6 PR 1

Autocomplete on the To" field adds @localdomain to whatever you type.  

Reproducible: Always
Steps to Reproduce:
1. compose new mail
2. type recipient_name

Actual Results:  autocomplete addresses to recipient_name@localdomain

Expected Results:  don't autocomplete unless there's a match
Keywords: nsenterprise
QA Contact: esther → fenella
Didn't Communicator 4.x default to @localdomain if there was no other match?
I think the present bevavior is correct. In most companies a vast majority of
messages is sent to people in the local domain. 

I vote for marking this bug INVALID. I would advise you to open another bug
about a pref to change the present email autocomplete behavior.
bugzilla search is not working now, but it might be useful to consider an RFE I
filed, where I suggested that mozilla should have its own user-configurable
"default domain", to override the various quirks and networking problems that
come with letting the OS handle default domain searching and resolution.
autocomplete is compose, over to ducarroz.
Assignee: sspitzer → ducarroz
Component: Mail Window Front End → Composition
Mozilla supports "multiple domains".  Auto-completing in this environment is
very, very confusing.  Let the mail server do that.  Don't do it in the client.

For instance, I have an accout at "", but return address is configured
(for this account) to be "".  When I select the Inbox for, then
address a new mail message by using only a "first name" without a domain, the
client completes this address using "" as the domain.  This is wrong. 
And it's far harder to get it "right" than to turn it off and let the mail
server handle it.
Another issue.  Does it deserve another bug?
Another issue.  Does it deserve another bug?

If I address to "mitch, joe", the client will autocomplete to "mitch,".  Also wrong, I believe.  Don't let the client pick domains.  
BTW, this bug was submitted by the single largest customer Netscape has ever
had.  I'm just the scribe.
Mitch, I agree, I don't like the @localhost behaviour either. I would prefer
having autocomplete just suggest nothing.
So what about a pref for that. We can delault it to not complete, bt the user
could choose otherwise. I believe everybody would be satisfied by this.
No pref. Please.
Håkan: Can you elaborate?
any pref loses all meaning as soon as you add a second mail account with a
different domain.  
Elaboration: this imho not a feature, it's a bug and there should be no pref for
activating the bug. This functionality should be removed.
the autocomplete domain should be settable for each mail account, with the
ability to disable it for each account individually.  but there's so much user
confusion about "switching accounts" that i think we need to think carefully
about this before we exacerbate the problem.  as i said before, the mail server
can handle this task, we don't need to burden the client with it.  just say no.
Well, I meant per-account pref. Its GUI should be accessible from the same pane
as "Attach this signature".
Not all mail servers can handle this (even as I agree that most can). 

And I'm sure that mail sent from my home computer (local ISP's server) to
someone at my company needs the domain, even as my DNS settings have the work
domain set (to enable me ssh, ftp etc. without attaching domain).
If the fix for this bug is that we shouldn't auto-append the domain for the
first choice in the autocomplete dropdown list of choices (showing what I
typed), then that's probably fine. If it is more than that, I'd like to know
what it is.
Kmurray: if I type in "kevin", it auto-appends That's what this bug
is about.
Yes, thanks. What I'm asking about is the resolution. We might consider a single
behavior change instead of completeley removing the function altogether. As
Jacek suggests, we should plan on making this per-account pref-controlled (and
append is *on* by default), only because I believe that the masses find value in
this, but some enterprises do not. What are some alternatives to preserving the
consumer value, and providing some flexibility?
I disagree. Adding a pref for every design decision is just a poor workaround
for doing a real decision. Remember, for every pref you add, you expect the user
to make a choice. With the amount of choices we have (read prefs) in Mozilla
currently, it's just going to be a pain.

This "feature", is annoying because autocomplete is supposed to take my stored
address-book cards and suggest an email. If the email isn't know, it will
remember it upon send. Adding the localhost to an address rarely helps, and if
this annoyance can be removed - it should be.
For me it is not an annoyance. For my boss (who still uses Netscape 4.*) it is a
must feature, as he sends 90% of messages to the same domain. I find this
strange that people try to change a 4xp behavior they do not like, without
letting the ones who like/need it restore it if they choose to. Remember that
most of Mozilla/Netscape 6 users will be former users of Netscape 4.*.
<<Adding the localhost to an address rarely helps>>

What's the basis for "rarely?" Do you mean rarely helps *you*? I'm thinking that
most novice/intermediate users will and do benefit from this.
"This "feature", is annoying because autocomplete is supposed to take my stored
address-book cards and suggest an email. If the email isn't know, it will
remember it upon send."

Bingo.  And in a corporate setting, the matches will come from the corporate
LDAP directory as well, further eliminating the need to append the corporate
domain. If the client can't match based upon my address books or directory, then
don't make assumptions.  Right, "Kevin Murray" <>?  

As for the argument that we shouldn't change 4.x behavior without warning.... 
The current behavior in 6.x IS a change from 4.x.  In 4.x, it did autoappend the
domain name of the sender to all typed addressees that didn't include the
@domain suffix, but it also supplied matches.  The default selection (the one
picked if the user just hits <return>) is NOT the auto-appended version, but the
first actual match.  Netscape 6.x picks the auto-appended version instead.  Try it.
I agree with Mitch Green, the current Mozilla setting *is* different from
Netscape 4 :

Expected result (Netscape 4) :
I have LDAP directory and personal address book search enabled :
I type the start of a name then TAB to go to next field
Netscape 4 finds an LDAP match and uses it as autocomplete

Buggy behaviour (Mozilla 0.9.3) :
I have LDAP directory and personal address book search enabled :
I type the start of a name then ENTER to go to next field
Mozilla proposes a @localdomain autocomplete and the LDAP match, but it uses the
@localdomain autocomplete rather than the LDAP match !!

So IMHO the Netscape 4 behaviour should be reproduced in Mozilla : if a match is
found, Mozilla should autocomplete (when ENTER or TAB or LEFTCLICK is used) with
the match rather than using @localdomain...
I'm a bit fuzzy as to part of the problem here. If there's an exact match and
you just hit enter or tab to the next field we don't select the @localdomain
option. We properly finish the auto complete with the exact match. 

It's only in the case were there are multiple partial matches that the default
@localdomain option is selected if you hit enter or tab. 

i.e. I type:


which matches
Ben Smith <>
Ben Klein <>

if I hit enter or tab then we automatically just do ben@default domain

If there's an exact match. I type Ben S then I hit tab or return the auto
complete widget properly selects the exact match and not the one with the
default domain. 

If this bug is to complain about the fact that in the first case, we should just
pick the first partial match instead of the @default domain then this bug should
be marked a dup of 88315 where we are currently trying to figure out if that's
the right behavior we want or not. 

mscott :
If the unique match is in an address book everything is working properly. It is
when the unique match is on a *LDAP directory* that the problem shows up :

Suppose the following situation : "def" brings a unique match in an address book
and "del" brings a unique match in the LDAP directory. "de" brings the two
matches, one on each.

Test 1 : address book and LDAP search enabled
I type "def" : autocomplete is OK to the unique address book match
I type "del" : autocomplete uses del@localhost rather than the unique LDAP match
I type "de" : autocomplete is to the address book match 

Test 2 : address book search DISABLED and LDAP search enabled
I type "dfe" : autocomplete is OK to the unique LDAP directory match !!

So the problem is when the unique match is on the LDAP server *AND* address book
search is also enabled. I suppose there's something wrong in the search
priorities. Also note that in the case Test1/"de", since there are two matches,
it could be considered abusive to prefer the address book match over the LDAP match.
Sorry for the spam :
On Test 2 one should of course read "del" and not "dfe"
QA Contact: fenella → nbaca
Reproduced in Mozilla 0.9.4 (Build ID 2001091303) on Win32.
Specific issue when there is a unique match on a LDAP directory filed under a
new bug 101498.
cc'ing dmose. 
Target Milestone: --- → mozilla1.1
Why did this request get dropped?

I find the autocomplete VERY annoying and would like a pref to
turn it off.

Especially since I many times use Mozilla Mail to paste munged addresses in such
as <kelleycook at dwhoops dot info> and it will "helpfully" add in a to the end.

Please allow me to turn off this annoying "feature".
This drives me batty.

Seems like the solution is:

When there are multiple matches, show matches in this order:
  - local
  - LDAP server 
  - @samedomain.tld
and use the first match as the default autocomplete.

This addresses the following issues:

[Corporate] Users of prior versions expect autocomplete for users at their own
domain. This still works. 

[Corporate] Users using LDAP server will get the LDAP match first.

Home users, who are no more likely to send to their own domain than any other,
will either be typing full addresses (autocomplete doesn't affect) or short
names for entries in their own address book, which will appear as first match.

[Corporate] Users who wish to override LDAP lookup or default domain can add an
entry to their local address book.

Also, I would suggest an advanced setting (about:config) that can turn off the
samedomain autocomplete entirely, so those who get really incensed about it have
an option, but it doesn't clutter up prefs.

Seem fair?
*** Bug 235580 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
Blocks: 235580
This is a bug because mozilla and thunderbird do not complete with localdomain
but with the sender domain. If autocomplete is desired, the email address should
be completed with the domain of the smtp server.

Example: I have the private email-address 
I want to send an email to my co-worker joe and I use as the
MTA in our company. 

So if I type a receiver address of "joe" and give this to, it
means But mozilla and thunderbird make, which is nonsense!
Actually, there seems to be a genuine bug here, even with the existing
functionality as it stands. Perhaps I should open another bug? 

Using Moz 1.8a3, but I think this has happened as long as I can remember.

Sometimes, even though you did type in an address that should match something in
your address book, Mozilla adds @localdomain anyway.

It seems to be timing related. I can reproduce it frequently by typing something
in, then editing so it should match an address book entry and quickly tab or
enter. If I time it right, mozilla adds Go back, take the
@localdomain off, tab away and Mozilla picks up the address book entry.

This is more irritating than the default of always adding @localdomain, because
it makes it unreliable/unpredictable.

I can't isolate exactly what causes it, but it happens maybe 20% of the time.

My example: I have an entry in my address book for "Dad Lawrence
<>". I type muddle into the To: address to get this address. 
This bug as reported is essentially the same as bug 100207, which was wontfix'd 
by Asa.

(In reply to comment #36)
> Sometimes, even though you did type in an address that should match something
> in your address book, Mozilla adds @localdomain anyway.
> It seems to be timing related. I can reproduce it frequently by typing
> something in, then editing so it should match an address book entry and
> quickly tab or enter. If I time it right, mozilla adds

There are other fast-typing/autocomplete bugs -- bug 163103, bug 143669 -- but I 
would say that warrants a separate bug.
Before closing this bug, I would ask that you please reread comment #32.  

Cut and Pasting a munged address that I need to edit is not related to
fasttyping bugs.

And that "feature" can be reproduced every time.  Highlight and copy 

"Kelley Cook <kcook at gcc dot gnu dot org>" 

and paste into a To: or Cc: field within the mailer.

It will changed to "Kelley Cook <kcook at gcc dot gnu dot org>"

This particular bug is a request to allow that particular last resort
autocomplete to be turned off for those that find it unhelpful.
There should be a way to turn this behavior off.  It's frustrating when one cuts
and pastes addresses, and makes no sense to most users (who are more often than
not E-mailing someone on the same domain).

Please DO NOT close this issue.
What drives me up the walls is that I commence writing in an address and it
autocompletes to @myISP.  And since I didn't know an error was made in typing
the address, I assume it auto completed to an entry in the address book.  By
this time I am typing in the subject or body field and don't see what occurred
until the rejection msg is received from the ISP.  And that msg may be received
the next day, consequently an important msg is inordinately delayed.
Target Milestone: mozilla1.1alpha → ---
Product: MailNews → Core
*** Bug 272550 has been marked as a duplicate of this bug. ***
It is simple:

Some corporate users use this bug (or function?) regulary becouse they are used
to it. It this dosen't mean that it would be a good solution. 
Please consider the following: the ONLY right solution is, that autocomplete
finds EXISTING mail addresses! In a corporate environment it should find the
corporate addresses (LDAP match).
Suggestion: You must go for the right solution, but you have to care for the
existing corporate users. 

Suggested solution: Create an option to swich the localdomain autocompletion off
while the  normal autocompletion still works.  The default value shold be "on",
so that corporate users don't loose the "funtion", and the annoyed private users 
may swich it off. 

Please fix it before I switch to Outlook:)


*** Bug 275864 has been marked as a duplicate of this bug. ***
*** Bug 276875 has been marked as a duplicate of this bug. ***
*** Bug 287103 has been marked as a duplicate of this bug. ***
I have this working in my tree...
Assignee: ducarroz → bienvenu
Attached patch proposed fix (obsolete) — Splinter Review
I'd also like to change addresses that didn't autocomplete (if autocomplete is
turned on) red, and put up a broken ab card, so users get quicker feedback.
I've changed the default for appending the domain to false - that may be too
radical, and I'm open to changing it back...

There's also an unrelated change, some cleanup in the setTimeout call, to pass
the function, and not a string, that Neil pointed out at one time...
Attachment #180060 - Flags: superreview?(mscott)
I think we have seen enough comments of annoyed users now. To keep most of them
satisfied (and isn't this an important task in software development?) there
really really should be some way to turn this bug off. A simple pref would be
perfect. Just don't let Thunderbird wildly guess nonsense addresses if there are
other ways to ensure a correct behaviour (i.e. LDAP, Collected Addresses or the
mail server solution). No pseudo-heuristic completion, please! This
auto-complete (or better auto-garbage) is often so stupid that I cannot edit an
e-mail address in the application (bug 275864, now a dupe of this). I need to
open a text editor then only to peacefully edit that address and then copy it
back to the composing window. Does that sound reasonable to you? Sometimes I
really have to ask myself who you are developing this application for. Surely
not for the end-user like me.
David: I was reading your patch. It seems good to me. Reusing subjectDlogTitle
for the title of the invalid address dialog though seems a bit deceptive, it
seems more like the name should be "sendErrorTitle" or something. 
Comment on attachment 180060 [details] [diff] [review]
proposed fix

do you think this should be an identity pref as opposed to just a global
yes, definitely. I made it an identity setting because you might have an
identity in your enterprise that wants to autocomplet to your enterprise domain,
but your isp identity does not...
Attached patch proposed fixSplinter Review
OK, I added code to allow turning this off with a pref,
Attachment #180060 - Attachment is obsolete: true
Attachment #182092 - Flags: superreview?(mscott)
Comment on attachment 182092 [details] [diff] [review]
proposed fix

don't forget the C++/IDL change from the earlier patch :)
Attachment #182092 - Flags: superreview?(mscott) → superreview+
Attachment #182092 - Flags: approval-aviary1.1a?
Comment on attachment 182092 [details] [diff] [review]
proposed fix

Attachment #182092 - Flags: approval-aviary1.1a? → approval-aviary1.1a+
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #180060 - Flags: superreview?(mscott)
This patch breaks my Linux (Fedora Core 3) build :-

/home/mozilla/mozilla/mailnews/base/util/nsMsgIdentity.cpp:576: error: extra
`;'gmake[5]: *** [nsMsgIdentity.o] Error 1

Looks like a very simple fix.
Resolution: FIXED → ---
Excellent, that fix dealt with my Linux and Win32 builds.
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
(In reply to comment #52)
> OK, I added code to allow turning this off with a pref,
> mail.autoComplete.highlightNonMatches..

David, could you clarify that a little?  Does this mean that 
  (mail.autoComplete.highlightNonMatches == False)
will suppress the @localdomain completion for all identities, and that
  (mail.identity.idX.autocompleteToMyDomain == False)
will suppress the @localdomain completion for idX?
mail.autoComplete.highlightNonMatches just makes us show non-matched entries in
red.  It's somewhat orthogonal...
Here mail.autoComplete.highlightNonMatches is set to true and addresses of the
form are shown in the same color as the matches from the
addressbook... (yes i got a build with the fix in it)
I can't send to mailing lists anymore because the prompt comes up before we
resolve the mailing list. I'll spin up a new bug for that. 
Bug #294107 filed.
Is there a UI for this? 
(In reply to comment #62)
> Is there a UI for this? 

No. You have to open the Config Editor (under Advanced in the Preferences) and
set mail.autoComplete.highlightNonMatches to true by doubleclicking on it.
*** Bug 309616 has been marked as a duplicate of this bug. ***
*** Bug 131692 has been marked as a duplicate of this bug. ***
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 "" but they wish to send all their emails to domain "". 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. 
Product: Core → MailNews Core
No longer blocks: 131692
Blocks: 131692
Blocks: 1138033
You need to log in before you can comment on or make changes to this bug.