Closed Bug 273019 Opened 20 years ago Closed 19 years ago

Address completion mangles address if you press enter before drop-down shows

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 261272

People

(Reporter: larsen, Assigned: mscott)

Details

Attachments

(1 file)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Thunderbird version 1.0RC1 

If I type for example "Alex" in the To: field and press Enter before the search 
results show in the drop-down, the following is inserted into the To: field

Alex <alex@domain.com>m>

Note the extra "m>" at the end. This causes a failed send. This happens for 
several different users in address book. A contributing factor may be that 
these users are both in my personal address book and are found in my LDAP 
server.

Another example with different results (I don't know why): I have a user in my 
personal address book (but not in LDAP) whose name is "Chris Kipling". If I 
type "kip" in the To: field and press enter before the drop-down shows, I get 
the following result in the To: field

Chris Kipling <kipling@subdomain.domain.com> >> Chris Kipling 
<kipling@subdomain.domain.com>

(not sure how word wrap will affect this post, but the above is one line in the 
To: field)

Even more extraneous stuff than the previous issue.

The subdomain in question is a subdomain of my domain, so in the example, my 
default domain is "domain.com".

This bug was also present in TB 0.9 and 0.8

Reproducible: Always
Steps to Reproduce:
1. type a few letters of a name in your address book
2. press Enter before the drop-down choices show on screen
3. see the mangled result

Actual Results:  
See details above. Mangled addresses are inserted into To: field

Expected Results:  
Insert a properly formatted email address.
See bug 261272.

Regarding your 2nd example, does "Chris Kipling" have a nickname that matches 
"kip"?
No, there is no nickname for that entry. I'm just counting on the completion to 
find it for me. If I type "kip", wait for the drop-down to show and then press 
Enter, it works as expected. The problem comes when you hit Enter before the 
drop-down is displayed.
I see something similar also. I see this in addressers in my personal address
book which *may* have been collected from an LDAP server.

I also see this with an entry I added manually but which has a nickname.

I see this on Windows and I think I saw it on Linux too but I'd have to check.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

L
I see this same bug using Thunderbird 1.0 on Windows XP, but the ramifications
are a bit worse.  My local address book knows about a Matt Kauffman.  When I
type in "Matt" in the "To: field and press enter, it autofills like this:

Matt Kauffman <mattk@company.com> >> Mary K Smith <marysmith@company.com>

Matt is in my local address book, Mary is in my LDAP address book.  If I send
this email, it doesn't go to Matt.  It goes to Mary.  Two of my coworkers report
the same problem.  We must constantly doublecheck and edit the To: line of
emails we send.
Same problem seen in Thunderbird 1.0 (20050201) on Linux (built from source on
Red Hat 7.3). Does seeing it in both Windows and Linux justify setting "OS" to
"ALL", on the assumption it really does occur on all other platforms? It sounds
like it may be a platform-generic piece of code.
Additionally, it looks like Thunderbird may be ignoring the user preference that
tells it to ignore the LDAP directory if a local match is found (which would get
around this problem).

i.e. my user prefs contain

ldap_2.autoComplete.skipDirectoryIfLocalMatchFound true

And I have a local address book entry with a nickname of "ted"
(ted.motty@first_host.com). However, when I type "ted" quickly and hit "enter",
Thunderbird still searches the LDAP directory (even though it would find exactly
one entry in the local address book), and appends the local and LDAP entries
together with:

Ted Motty <ted.motty@first_host.com> >> Collins Ted <tedcoll@second_host.com>
I'm having this problem too and it's annoying the heck out of me.  How can this
bug be almost 4 months old and still unconfirmed?
Is this the same issue discussed in Bug 278398
https://bugzilla.mozilla.org/show_bug.cgi?id=278398
Just a thought as they sound similar.
I've exactly the same problem.
Thus when TB (1.0.2-1.3.2 (20050324)) has matched against an entry in my
'collected adresses', it will still also match against an entry in LDAP, thus
leaving me with two e-mail adresses. The LDAP entry useally appears when I'm
already typing the body.
OS: Fedora Core 3
This seems to be related to the presence of an LDAP directory, or maybe simply
with matching entries from multiple address books.
The first line is obtained by typing Ema<ENTER> as address. The displayed match
is from the personal address book, followed by a part of another match (from
where, I don't know, as I see only the domain -- but it's not always the case,
sometimes only a part of the domain is displayed, sometimes there is also part
of the user).
The second line is obtained by typing anti<ENTER>. If it's not clear, the
result is antifumo@bluemail.ch >> Name <name@epfl.ch>. "antifumo@bluemail.ch"
is an e-mail address from collected addresses. The part after the >> is a match
from the LDAP server.

(Sorry for having "obfuscated" some parts of the addresses, but I'm not sure
the persons involved would apperciate if I publish their addresses here...)
I have several users that are experiencing this behavior as well, exactly as
described with the "m>" added to the end of the email address rendering it
undeliverable.  

Thunderbird 1.0.2 on Windows XP and 2K
The symptom originally described in this bug is v. similar to that at 
bug 261272, which has been fixed (since late May) in post-1.0.x build of TB.  
Jeff Larsen (and other reporters here), do you still see the symptom with 
1.5/1.6 builds of TB?

See also bug 278398.
I am not seeing this issue in TB 1.5 beta 1.
Ditto -- the problem no longer occurs in 1.5b1. Thanks, Mike.
OK, duping.

*** This bug has been marked as a duplicate of 261272 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: