Closed Bug 278398 Opened 20 years ago Closed 19 years ago

address typed gets replaced with first email address from dropdown list after Tab is pressed

Categories

(Thunderbird :: Message Compose Window, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: firefox, Assigned: Bienvenu)

References

Details

(Keywords: fixed1.8)

Attachments

(1 file, 3 obsolete files)

When I type the address to To: field and press Tab, Thunderbird replaces the
typed address with first address in dropdown list. Very annoying. I have even
sent email to wrong person because of this "feature".

Solution: After pressing Tab, keep the address typed, and move to the row below
(e.g. CC:)
Severity: normal → minor
Whenever I type an address, as soon as the typed letters don't match any address
book entries, the drop-down disappears.

e.g. joe@bloggs.com will disappear from the list as soon as I type joe@s (for
joe@smith.com)

Tb 1.0/WinXP
It does not dissapear for me. It is still there, even if the address is
different. Win2K + Thunderbird 1.0
Reporter, please be a little more descriptive.  What exactly has been typed, 
what appears in the list, and what is left in the field after you type the Tab?
Exact address being typed in To: field:
info@enjoyslovakia.com

address in To: field after pressing TAB:
ZOZNAM info <obchod@etarget.sk>
^^^^^
this address has been added long time before to Collected addresses
(automatically as Thunderbird does it always).

Also, pretty strange thing maybe related to this:
info@enjoyslovakia.com
is never shown in dropdown menu, even I have send over 20 emails to this address
and I suppose this address should be automatically inserted into Collected
addresses (actually, it is there, I've just checked Address book).

info@enjoyslovakia.com is stored under "info" (no quotes) in Collected addresses
(In reply to comment #4)
> Exact address being typed in To: field:
> info@enjoyslovakia.com

You typed that entire address string?  Or you just typed "info"?


> address in To: field after pressing TAB:
> ZOZNAM info <obchod@etarget.sk>
> ^^^^^
> this address has been added long time before to Collected addresses

When you type "info" into the field, the list of suggestions will match on names 
before it matches on addresses.  Since "ZOZNAM info" includes the word "info" 
(presumably stored as the "last name" of the address), that's the first choice 
as long as you've typed only "info".  But if you type the @ sign, the dropdown 
menu closes (or at least, it closes on my system).


> Also, pretty strange thing maybe related to this:
>   info@enjoyslovakia.com
> is never shown in dropdown menu...
> 
> info@enjoyslovakia.com is stored under "info" (no quotes) in Collected
> addresses

That may be related, yes.
(In reply to comment #5)
> (In reply to comment #4)
> > Exact address being typed in To: field:
> > info@enjoyslovakia.com
> 
> You typed that entire address string?  Or you just typed "info"?

The whole email address including @domain.com

> > address in To: field after pressing TAB:
> > ZOZNAM info <obchod@etarget.sk>
> > ^^^^^
> > this address has been added long time before to Collected addresses
> 
> When you type "info" into the field, the list of suggestions will match on names 
> before it matches on addresses.  Since "ZOZNAM info" includes the word "info" 
> (presumably stored as the "last name" of the address), that's the first choice 
> as long as you've typed only "info".  But if you type the @ sign, the dropdown 
> menu closes (or at least, it closes on my system).
> 
It doesn't here... It just stays open with ZOZNAM info as first item and when
TAB is pressed, you know what happens.
Please list the contents of the NAME (first, last, display, nick) and INTERNET 
(email and additional email) fields of the address cards for both ZOZNAM info 
and info@enjoyslovakia.com.

Both cards are *only* in the Collected Addresses book?
for info@enjoyslovakia.com:
"Email" field: info@enjoyslovakia.com

fo zoznam:
"Display" field: Zoznam INFO
"Email" field: obchod@etarget.sk
I am unable to reproduce this problem, even if both address book cards are 
placed in the Collected Addresses book.  (You did not respond to the query 
regarding this point.)

Do you have any extensions installed which could be causing this problem?  Do 
you see the same symptom if you start Thunderbird in Safe Mode?
(In reply to comment #9)
> I am unable to reproduce this problem, even if both address book cards are 
> placed in the Collected Addresses book.  (You did not respond to the query 
> regarding this point.)
> 
> Do you have any extensions installed which could be causing this problem?  Do 
> you see the same symptom if you start Thunderbird in Safe Mode?

Yes, both addresses are only in Collected addresses book.

Here's the deal on this, and this should be considered a P1 IMHO.   This occurs
when you start to type a new addr, the dropdown suggestion list comes up, and
you finish typing the email addr out and hit enter *before* the drop down list
goes away.  This is easy to do as the list stays up for about 3 seconds.

I just sent an email message to my BOSS that was intended for MY WIFE.  This
message was NOT ok.

PLEASE fix this bug.  Otherwise I can't use Thunderbird at all.

(In reply to comment #11)
> 
> This occurs when you start to type a new addr, the dropdown suggestion list
> comes up, and you finish typing the email addr out and hit enter *before* the
> drop down list goes away.  This is easy to do as the list stays up for about
> 3 seconds.

Yes, that is easy to reproduce.  I see it with TB 1.0, Win2K; not with 
Moz 1.8b-0120.

xref bug 261272
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is anybody working on this? This is so annoying that I have already sent about 3
messages to wrong persons!!! You know, how this could be potentially dangerous.

Please, change to major severity.

I suppose many people have these problems typing fast and dropdown menu does not
go away, rather it stays and put wrong address there. This applies for both TAB
and ENTER keys.
Typing the same string at different cadences produced different matches in the
address book.  This occurs when adding an address while composing a message.

Here's an example of incorrect substitution.  It appears to be a timing problem
with the matching of entries in the address book.  The cadence at which you type
changes what is substituted.  I'd guess the code fails to wait for a thread to
complete.  

The example:  I have ryder and rtoth in my address book.  Ryder appears first in
the drop down menu.

If I type r in the address field both show up, ryder first.  If I hit return at
this point ryder is correctly substituted.  If I type ryder<CR> ryder is
substituted.  If I type rtoth<CR> "SLOWLY" rtoth is substitutued.  All of this
is correct.

And the problem:  if I type r, then pause, then quickly type toth<CR> ryder, not
rtoth, is subsituted.  If I delay before typing the <CR> rtoth is substituted. 

I seems that <CR> takes the first match even if the match algorithm is active
and updating the match. I can repeat this with many other names.  The key is to
have a common prefix. 
Similar issue to Bug 265509 ?
(In reply to comment #15)
> Is this the same issue as Bug 273019
> https://bugzilla.mozilla.org/show_bug.cgi?id=273019

Possibly related, but not the very same.
(In reply to comment #16)
> Similar issue to Bug 265509 ?

Similar, but again, as I don't have the latest night build I can't test it if
the current bug https://bugzilla.mozilla.org/show_bug.cgi?id=278398 has been
resolved, too.

Can someone test it? There have been at least two descriptions on how to reproduce.

*** This bug has been marked as a duplicate of 290878 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Reopening.  This can't possibly be a duplicate of bug 290878 for three reasons:

1)  That bug was _only_ about clicking in the dropdown
2)  That bug was a regression caused on April 16, 2005, while this bug was filed
    in January 2005.
3)  That bug is fixed and this one isn't.

This last is rather key.  Please be more careful when marking bugs duplicate.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Please, could someone fix this finally!? I am constantly having stupid
situations while explainign why I have sent email to wrong person with very
sensitive data!!!

How is it possible that Thunderbird is so stupid when enetring info@xxx.com and
pressing TAB immediately (e.g. first 2/10 of second), it changes the address to
info@yyy.com ????

SERIOUS PRIVACY BUG! 
Severity: normal → major
Flags: blocking-aviary1.1?
Dan, have you tried a recent trunk build?
Sorry for being angry, but it is really awkward to send sensitive data to some
other person just because I am typing faster than the Thudebird works...

No, I haven't tried trunk build. I am going to download it, test it and tell you
the results.
OK, I have downloaded and checked the nightly trunk release. The bug is still
there. 

Exact steps to reproduce are:
1) do have few addresses in your address book (collected addresses) with same
first few characters, e.g.:
info@domain.com 
info@wrongdomain.com
info@newdomain.com
2) press "Write" to create a new email
3) click to To: field
4) start typing info@undomain.com very slowly, type just first two characters: in
5) wait for dropdown list of addresses to display
6) start typing very quickly the rest of the email address: fo@undomain.com
7) you must type VERY FAST, so dropdown menu stays on the screen
8) you need to press TAB button when finished writing: info@undomain.com (again:
very fast!)
9) address changes to info@domain.com from dropdown menu list (or any other
address that is display as first one in dropdown menu)
*** Bug 297301 has been marked as a duplicate of this bug. ***
Same here under Linux (Fedora Core 3's Thunderbird 1.0.2), so please change OS
to "All".

Just got bitten, causing a private mail to be sent to a mailing list. The nasty
part is that this bug tends to misaddress mail sent to the people you know best,
because you type their e-mails quickly enough to trigger it...
Very, very true, unfortunately.
OS: Windows 2000 → All
I saw this in 1.0.2. but am still unable to reproduce it on the 1.1 nightlies. 
Can any of you help us get this isolated? Time is short for our upcoming releases.
I can reproduce this on the trunk, but it's really quite hard to reproduce and I
wouldn't hold the release for it by any means. The trick is to type _very very
quickly_ and slam on the tab key as fast as possible. I can't see how anyone
would send mail to the wrong person with this unless they were typing incredibly
fast. 

What it looks like is that the autocomplete box goes away a very short while
after a non-autocomplete-matching character is entered, rather then at the same
time. As such, if you manage to hit tab before the autocomplete clears, it will
still take the autocomplete address rather than the entered address. Waiting a
moment lets the autocomplete go away, and the entered address is used instead. 
As a pragmatist, Zach, people _obviously are_ sending mail to the wrong people.

For me personally I have a Jean and a JC in my addressbook. Depending on the
cadence/rhythm of my typing, it autocompletes with a different name. As Zach
says, the autocomplete isn't instant and so if I type J..*pause*..C [tab] I get
Jean (as that is what is completed for "j" alone) but JC..*pause*.. [tab] gives
a different result. It doesn't require incredibly quick typing; only for the
last letter(s) to change the autocomplete. 

I don't know if this problem is still in the nightlies (I don't use them) but my
guess at the problem is that the autosuggest needs to be updated after every
keypress and _before_ the address is autocompleted/filled in.

It isn't that this problem occurs often, it is that if it does and the user does
not realise, the problems which it can cause are really serious.
Re:#30: "Very very quickly" is relative. On a slow computer, this happens a lot 
more often. Also, I think (unverified) that the richer your address book, the 
more likely it is to happen. BTW, it also happened to me a few times when using 
Enter rather than Tab.

Since people have friends, business contacts, employees, managers and business 
competitors on their mailing lists, the effects of this bug can be devastating. 
Mistakenly sending to a competitor (or contractor, or whatever) something that 
meant for your manager can easily cost you your job; I am sure you can think of 
other, equaly horrid examples. The importance of this bug must not be 
underestimated.
(In reply to comment #30)
> I can reproduce this on the trunk, but it's really quite hard to reproduce and I
> wouldn't hold the release for it by any means. The trick is to type _very very
> quickly_ and slam on the tab key as fast as possible. I can't see how anyone
> would send mail to the wrong person with this unless they were typing incredibly
> fast. 

It doesn't require much knowledge to reproduce this bug. Especially when having
lot of contacts, it is actually very _easy_ to reproduce. As long as there is
possibility to send email to the wrong person and as Tal Cohen said you could
have even sent email to the competitor, this is very serious privacy issue. Not
talking about private emails sent out to mailing lists, business partners and so on.
We need to consider finding and including a fix for this for the next release.
Scott, can you dig into this? Is there a better person for that?
Flags: blocking-aviary1.5? → blocking1.8b4+
I can reproduce this - in general, it's a lot harder than it used to be, but it
can be done if you try really hard.
Assignee: mscott → bienvenu
Status: REOPENED → NEW
(In reply to comment #35)
> I can reproduce this - in general, it's a lot harder than it used to be, but it
> can be done if you try really hard.

I can reproduce it systematicaly and very easily (trunk 20050810):
- I have only three addresses started with "jo": joe@foobar.com,
john@barfoo.com, jonny@farboo.com 
- I type "jo" and wait for the dropdown to appear.
- then I quickly type "h<tab>" to have the second name completed (<tab> must be
pressed before the dropdown disappear).
=> joe@foobar.com is substituted (ie the first name).

It also happens with only two addresses, except that the dropdown never shows up
(is it on purpose?)
this could be a pretty tricky autocomplete widget bug. I suspect the tab key
causes us to select the currently selected item before we have finished refining
our autocomplete matches with the newly typed character.
yes, that's what's happening. I have a fix for this, but it makes us always turn
the address red, even if it was a match...
Attached patch possible fix (obsolete) — Splinter Review
this is something to try - it fixes the problem I was able to reproduce, but I
don't have a high confidence level that this is the right fix...
Attachment #193025 - Flags: review?(neil.parkwaycc.co.uk)
*** Bug 303996 has been marked as a duplicate of this bug. ***
(to #37) It was noted before, but should be stressed that the bug also happens 
with the Enter key, not just with Tab.
Whiteboard: [needs review neil]
Neil, do you think you'll have a chance to review this soon?

Time is running out if this going to make the next release.
Comment on attachment 193025 [details] [diff] [review]
possible fix

>+          // if the user typed, don't use this.value, because it could
>+          //  have been an autocomplete from the last text.
>+          if (this.value != this.currentSearchString)
>+            this.value = this.currentSearchString;
>           var str = this.value;
I'm not convinced about this. I'd be happier if you didn't change the current
value, but simply searched for the saved search string.

>+              if (this.isWaiting || this.mNeedToFinish) {
>                 // if a search is happening at this juncture, bail out of this function
>                 // and let the search finish, and tell it to come back here when it's done
>                 if (this.isSearching || this.isWaiting) {
>                   this.mFinishAfterSearch = true;
>+                  this.mDefaultMatchFilled = false;
>                   this.mFireAfterSearch = aFireTextCommand;
>                   return;
>                 }
I'm not convinced by this either. It looks to me as if we need to check for
isSearching or isWaiting earlier (i.e. just after checking for forceComplete).
Hopefully this won't regress bug 244522 either.
Attachment #193025 - Flags: review?(neil.parkwaycc.co.uk) → review-
minusing. Will consider a safe patch if one develops. 
Flags: blocking1.8b5+ → blocking1.8b5-
Whiteboard: [needs review neil]
Attached patch proposed fix (obsolete) — Splinter Review
Neil, is this what you had in mind? It does seem to fix the problem for me...
Attachment #193025 - Attachment is obsolete: true
Attachment #198049 - Flags: superreview?(neil.parkwaycc.co.uk)
Comment on attachment 198049 [details] [diff] [review]
proposed fix

When I tried this I actually got an incomplete completion, although I haven't
looked to see if I can see why; the steps I took were to press C, which gave me
a list of first and last names beginning with C, I then typed H as that was
unique to the last name and I pressed tab very quickly. The result was ch >>
Jesus Christ (it's a test address card!). It also didn't close the popup
correctly, which confused me somewhat as my keyboard focus went haywire. I'm
guessing that the if (this.isSearching || this.isWaiting) condition needs to
set mFinishAfterSearch and mFireAfterSearch here, obsoleting some of the
mNeedToFinish code.
Attachment #198049 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview-
Attachment #198049 - Attachment is obsolete: true
I can recreate the drop down not closing w/o my patch, on both the trunk and the
1.8 branch, so I doubt that has anything to do with my patch. I'm not sure I
understand your other problem - did it not pick the first thing in the list that
matched ch?
It did, but only as a "suggestion" i.e. with the >> indicator.
The patch could also shorten the interval, so it doesn't take that much time to
display suggestion. E.g. suggestion should be displayed on typing with no delay.

On writing To, I should be displayed immediately Tomas <tomas@tomas.com> and not
only after waiting one second for something to come up. That's usability bug
that has lot of do with the current bug I guess.
(In reply to comment #48)
> It did, but only as a "suggestion" i.e. with the >> indicator.

This is the symptom fixed at bug 261272.
Yes, but with attachment 198049 [details] [diff] [review] that regresses for local address books too...
On the count of beating the dead cow, here is my experience of this bug:

I run a P3-600 WinXP TB 1.06
I have about 150 addresses in my address book.

Now if I type the beginning of an address half way through an autocomplete
address is shown, and the selection drop down list shows up. If I now quickly
type all the rest of the address the autocomplete suggestion goes away, the
selection dialog remains visible. When I then quickly press enter or tab, my
fully typed address is replaced by the one shown for autocompletion before.

I want to stress that I typed the whole address, so no autocompletion should
have taken place, nor was there any autocompletion visible in the address bar,
only the drop down list was still present when I press enter or tab. I think
this could be an issue of TB trying to find an address to suggest for
autocompletion from the new characters I type, but its not fast enough, and when
I press enter it has not yet realized that its suggestion is not suitable any
more. It could be imagined that this is more likely to happen on slow computers,
thus making it difficult to reproduce for developers with fast machines ? 

Maybe this bug could be resolved by re-checking the suggestion with the actual
content of the address bar when enter or tab is pressed.

I can reproduce that error 100% of times. This is really annoying and I would be
very pleased if you could fix it.

If you need further info or want me to test a windows binary, just email me please. 

Cheers,
Karl
Attached patch My go at a fix (obsolete) — Splinter Review
OK, so I had some spare time and managed to have a go at a fix.
Attachment #198571 - Flags: superreview?(bienvenu)
Attachment #198571 - Flags: review?(mscott)
OK, my turn to rain on the parade :-( I tried this with a local AB. I have an
Aaron in my AB. I typed a, waited for the autocomplete dropdown, then typed
a<tab> quickly. I was left with aa in the to: field. If I click back to the to
field, I get Aaron's address.
Attachment #198571 - Attachment is obsolete: true
Attachment #198808 - Flags: superreview?(bienvenu)
Attachment #198808 - Flags: review?(mscott)
Comment on attachment 198808 [details] [diff] [review]
Only ignore the completion if we are waiting.

this works much better, thx very much!
Attachment #198808 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 198808 [details] [diff] [review]
Only ignore the completion if we are waiting.

Let's get this on the trunk and since it's seamonkey/thunderbird only, we may
have some flexibility about taking it on the branch if it looks good.
Attachment #198808 - Flags: review?(mscott) → review+
Fix check in to the trunk.
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Comment on attachment 198808 [details] [diff] [review]
Only ignore the completion if we are waiting.

I'm going to approve this for the branch. Effects seamonkey and thunderbird
only. No firefox impact.
Attachment #198808 - Flags: approval1.8rc1+
Keywords: fixed1.8
Comment on attachment 198571 [details] [diff] [review]
My go at a fix

clearing obsolete requests
Attachment #198571 - Flags: superreview?(bienvenu)
Attachment #198571 - Flags: review?(mscott)
There seems to be a related problem that is well described by the subject of this bug report although the problem is not exactly the same as Dan's description.

To reproduce:

1) Put these test entries in your Personal Address Book:

First Name: Ruth
Last Name: Frietchen
Display: Ruth Frietchen
Email: ruthy@holycow.com

First Name: Ruth
Last Name: Suchecki
Display: Ruth Suchecki
Email: oprah@nomore.com

2) Go to a blank TO field, type ruth and nothing else.  Problem:  there is no drop-down and only the first entry is shown.

3) Go to a blank TO field, type r and wait.  The drop-down appears and both entries are correctly shown.  Type the rest of the name (uth).  The drop-down remains and both entries are still correctly shown.

It seems to me that the speed at which I type the name ruth should not determine whether or not the drop-down box appears.

This behavior did not change for me when the fix was applied between beta 1 and beta 2.  The problem also occurs after I have manually disabled all extensions.  (By the way, Thunderbird's -no-extensions option doesn't seem to work anymore in beta 2, at least not for me).

I'm using Thunderbird 1.5 Beta 2 (20051006) on WinXP.
Also, in another situation that's similar to Dan's report, TB beta 2 is still ignoring what I typed and replacing it with something else.

To reproduce this:

1) Start with an empty Personal Address Book.  At the least, you must add these entries to the address book in the following order because apparently the physical order of the entries in the disk file (abook.mab) affects the behavior of address autocomplete!

First Name: Gary
Last Name: Roberts
Display: Gary Roberts
Email: hello@there.com

First Name: Ruth
Last Name: Frietchen
Display: Ruth Frietchen
Email: ruthy@holycow.com

First Name: Ruth
Last Name: Suchecki
Display: Ruth Suchecki
Email: oprah@nomore.com

2) Go to a blank TO field, type r, and wait for the drop-down.  You should see that Gary is listed first in the drop-down and then the two entries for the Ruths.

3) Type uth<tab> without waiting for the drop-down box to update itself.  TB unexpectedly populates the TO field with Gary's entry instead of either of Ruth's entries.

(I'm using Thunderbird 1.5 Beta 2 (20051006) on WinXP)
Are you really using (20051006) ? Because this fix was only checked into the 1.5 beta branch on 10/17
Thanks for the correction.  I apologize for not realizing that this fix was not included in beta 2.  I'll re-run my tests when beta 3 is released.  Thanks.
Well it looks as if this has reared its ugly head Again.

I've only just notice this today in version 17.0.6.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: