Closed Bug 1107844 Opened 10 years ago Closed 10 years ago

Recipient autocomplete: For multiple matches, select dropdown result other than first using mouse click, confirm with Tab or Enter, and TB uses 1st result instead (i.e. private msg gets easily addressed and sent to random recipients)

Categories

(Thunderbird :: Message Compose Window, defect)

31 Branch
defect
Not set
critical

Tracking

(thunderbird_esr31 affected)

VERIFIED FIXED
Thunderbird 37.0
Tracking Status
thunderbird_esr31 --- affected

People

(Reporter: danieldimov, Assigned: mkmelin)

References

Details

(Whiteboard: [No me-too's, see similar bug 1152517, or open new bug][FIXED for TB 31.5 by bug 1043310, per comment 62])

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:33.0) Gecko/20100101 Firefox/33.0.2 Waterfox/33.0 Build ID: 20141106202217 Steps to reproduce: This bug is NOT present in version 24.3. It is present in version 31.3 Pre-requesties: in the address book there is few addresses starting with same characters - for example: danieldimov@gmail.com, danielminev@gmail.com, daniel@abv.bg Step 1: you type one or more characters that match to two or more e-mail addresses - the addresses are shown in a dropdown Step 2: you click with the mouse on second or third listed address Step 3: you hit Tab or Enter Step 4: the selected address is changed with the first one from the list Actual results: The result is wrong choice of e-mail address. Expected results: If you select entirely with the keyboard - the result is correct - NO BUG If you select with the mouse from the dropdown - there is bug It should be the same regardless what method you use to select!
I have the same bug with Thunderbird 31.3.0 on Debian.
Daniel, thank you for this well-formed bug report, happens exactly as described, on TB 31.3.0 (WinXP). Reminiscent of Bug 486501 and bug 533109, but this is actually a different bug and a bad one, too! I thought we also had a bug that clicking on autocomplete result should automatically create a new address line (which might be wontfix), but I can't find right now. This constitutes a massive and cunning violation of privacy, very hard to notice if user doesn't re-check recipient AFTER clicking Tab or Enter, for which under normal circumstances there's no need at all, plus the names might be similar so it's hard to notice. Magnus, can you comment?
Severity: normal → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mkmelin+mozilla)
Keywords: privacy
OS: Windows 7 → All
Hardware: x86 → All
Summary: e-mail address selection could be wrong if mouse is used → Recipient autocomplete: For multiple matches, select dropdown result other than first using mouse click, confirm with Tab or Enter, and TB uses 1st result instead
See Also: → 486501
After having someone recently complain about this, I did some tests to gather info. Using Windows Vista Thunderbird 31.3.0 I have three 'David's in my address book. Two have First name and first part of display name as 'Dave' A third has First Name and first part of Display name as 'David' One of these I use on a regular basis - call this 'Dave' number one. In TO field, type name, eg: 'dave' select Dave number 2 from dropdown. Upon press 'Enter' key OR 'Tab', the name and email address is changed to my most frequently used 'dave' number one. Also if I type 'David' to select a third different email address and different person, when you press 'Enter' key OR 'Tab', the name and email address is changed to my most frequently used 'dave' number one. Also I have other names eg: 'Daniel', upon 'Enter', email address is changed to an email address I have never 'sent' an email to, but do receive from...DAN is the display name for 'Devon Artist Network' email address. So it is not always choosing the most frequently used. if 'Dave' number one is selected then no problem. Most frquently used. If 'Dave' number two is selected then it reverts to Dave number one. If 'David' is selected, it reverts to Dave number one, but this may be because 'Dave' is higher alphabetically than 'David' and Dave number one more frequently used so selected above dave number two. IF 'Daniel' is selected, it reverts to 'DAN' (which is in 'Collected Addresses' and I've never sent to) is alphabetically higher than 'Daniel' which is in 'Personal Address Book'. Note: This problem occurs when you only use the autocomplete and press 'Enter' key OR 'Tab' key. It does not occur if you use autocomplete and select the next TO field by moving mouse pointer and clicking to move the cursor to next TO field... NOT using Enter or TAB. If using the 'Contacts Sidebar' - select names and click on eg:'Addto Bcc' button, then all names and address are entered correctly. But in these cases there is no need to use the 'Enter' key. If I deliberately place the cursor at the end of one of those names and use 'Enter', then it does not change, so this seems to occur only when using autocomplete. However, when entered via 'Contacts sidebar' they are always in red font - but that's another bug:) Please can this bug be elevated as it may cause personal information to be sent to wrong contacts. Many Thanks.
Confirming that this was tested in Thunderbird Safe mode with same results.
I concur with Anje and others that this bug should get elevated/escalated and fixed asap, then backported even to release versions. As confirmed by incoming user testimony here and on Bug 486501 plus dupe(s), this is a hazardous bug which can easily result in unnoticed, serious violations of user privacy when the message gets sent to random recipients which happen to be first on autocomplete's result list. -> Critical I know this might not match the typical definition of "Critical", but imo the scenario of privacy violation as described is just as bad as "loss of data". Here's why this is so cunning (cf. e.g. Bug 486501 Comment 17, or my comment 3 here): - In normal workflow, user will verify address just after SELECTION (when it's still correct), and THEN confirm with tab or enter. Per fundamental UX principles (violated by this bug), confirmation/focus change can never change anything here, so there's no need at all to still pay attention during or after confirmation. - Worse, even if you happen to keep your eyes on the ball around confirmation, you may not notice that TB randomly changed your recipient because it's in the nature of this bug that the wrong recipient's name/address might be very similar (even identical) to the intended recipient's name/address. Consequently, it's very easy with this bug to unwillingly send private messages to random recipients (even without noticing) - recipe for personal desaster and imho one of the biggest sins a mail client can commit!
Severity: major → critical
Summary: Recipient autocomplete: For multiple matches, select dropdown result other than first using mouse click, confirm with Tab or Enter, and TB uses 1st result instead → Recipient autocomplete: For multiple matches, select dropdown result other than first using mouse click, confirm with Tab or Enter, and TB uses 1st result instead (i.e. private msg gets easily addressed and sent to random recipients)
Whiteboard: [serious, unobvious violation of privacy; everyday regular usage]
Yes it should be fixed. My patch in bug 1043310 fixes it. I'm working on splitting that up now to get it through review.
Flags: needinfo?(mkmelin+mozilla)
I'm still getting a similar problem (TB 31.3.0). 1. Have two email addresses in my address book, call them: Jeanne Smith <Jeanne_Smith@gmail.com> Anne Jones <Anne_Jones@yahoo.com> When I type: Anne J Thunderbird (31.3.0) returns the Jeanne Smith email address. When I type: Anne Jo Thunderbird returns the proper Anne Jones address. Thia happens on all kinds of "similar pair" addresses, and has caused multiple headaches by sending an email to the wrong recipient. Thanks.
My IT department is frantically trying to revert from 31.3.0 to something like a 24 ESR before this does major and embarrassing damage. Our recommended workaround is to NEVER use the mouse on autocompletes, because it is a mixture of mouse and keyboard events that triggers the bug. Here is the failure scenario we see: - Begin typing a name in an address field. - Choose one of the suggestions from the drop-down list other than the top one BY CLICKING ON IT. - Hit ENTER to get a new blank address field. - Note that the address you just selected has changed to the first one on the list (maybe an event listener was still active for the now-hidden drop-down and triggered on the ENTER key as if the first row was being selected from the keyboard). The following procedure avoids the bug: - Begin typing a name in an address field. - To choose one of the suggestions from the drop-down list other than the top, use the down-arrow key to highlight it. - Hit ENTER to get a new blank address field or TAB to advance to the subject field.
I can confirm that bug (31.3.0, Win 7, on a 2000+ users nonprofit organization here in Italy), and i hope will be fixed soon, because can be very risky, and so i vote it as critical. Thanks.
Absolutely critical!!!!! ENTER or TAB should never nullify user's affirmative selection of a recipient.
+1 for critical - in a company environment with many users it is not practical to educate everyone about this bug. The sooner there is a fixed release the better.
(In reply to Magnus Melin from comment #7) > Yes it should be fixed. My patch in bug 1043310 fixes it. I'm working on > splitting that up now to get it through review. Magnus, could you please 1) provide a reference which of the split patches will fix this bug, and 2) file in a comment here a copy of the specific code which will fix this bug? I read through the patches but could not immediately identify the fix. We should push the fix for this bug to get reviewed and land asap, user/administrator feedback here suggests this is really hurting users on a massive scale.
Flags: needinfo?(mkmelin+mozilla)
Blocks: 1089711
It is bug 1043310, see the patch around the comment "EnterMatch was just called a second time" - which should be the issue in this bug. (If a "valid" match was already entered, don't do the default match case.") https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1043310&attachment=8538670
Blocks: 1043310
Flags: needinfo?(mkmelin+mozilla)
Another way around this bug is to enter enough of the name to make it unique that only one is autocompleted.
Blocks: 1113298
I can confirm having seen erroneous addressing caused by this bug - and confidentiality broken through misdirected emails. This is a dangerous embarrassment for users and should be elevated to critical.
I confirmed that the bug is also present on the Mac OS-X.
(work in bug 1043310 will fix this)
Assignee: nobody → mkmelin+mozilla
This is taking SOOOO LONG to fix. Can Mozilla push out the previous version (as an "update") in the meantime? Was there anything really overwhelmingly bad in the previous version?
This is a serious bug in the latest Thunderbird version (31.3.0) which I am surprised slipped through the net. I have reverted to the previous Thunderbird version (31.2.0) to avoid the risk of sending emails to the wrong recipients! I will upgrade to a later version when this bug has been satisfactorily fixed. Please tell me if there are any issues in the older version (31.2.0) which I need to be aware of. Thanks.
I, too, just rolled back to 31.2.0 and disabled auto-update. This is a serious problem for users who use enter or tab keys to enter an address from the auto list. It is way to easy to send a confidential email to the wrong person. More experienced users can work around by using down arrow keys, but training all users to change their method? Not realistic. All other email clients work the same as far as selecting the email address from a memorized list. Thunderbird 31.2.0 seems to work OK, but what are the risks of using the older version? It seems this bug has been noted for so long that it should have been fixed already. Anje's description above is spot on.
For those using Windows who want to revert: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/releases/31.2.0/win32/en-US/Thunderbird%20Setup%2031.2.0.exe I'm keeping TB 31.3.0 for a while because I was required to update the theme "TT DeepDark" when updating to TB 31.3.0 from TB 31.2.0 and am not sure if the current version of TT DeepDark is backward compatible.
Thanks for the tip, I have also just cured the problem by reverting to 31.2.0, reinstalling the same on my colleagues' machines and disabling updates. This bug is at best embarrassing and at worst downright dangerous. I hope it gets sorted out soon.
I've sent 10+ emails to the wrong people because of this bug, resulting in the release of confidential information to inappropriate recipients. Please fix!!
We backed out bug 1043784 from tb 31 ESR, so this bug is not as easy to hit anymore for tb 31.4.0 (to to released soon).
I am one of the many who have had to revert to 31.2.0 and disabled updates. If, as I understand, the fix has to wait for 31.4.0 and we have disabled auto-update and even update notification, please can you ensure that notification of release of 31.4.0 is added to this thread?
Voted, this is a serious privacy issue that has affected my users multiple times.
This bug may have been related to bug 970456 https://bugzilla.mozilla.org/show_bug.cgi?id=970456 ... please make sure the fix of that one doesn't undo the fix of this one. Both bugs change email addressing result for people using their own longstanding keyboard/mouse click routines to address email. So both bugs have resulted in people sending email to wrong addresses.
We need stable releases which I believe used to be done but has stopped now
By backing out bug 1043784 for thunderbird 31.4.0 this is now a lot less prominent. You don't need the Enter step after selection so the "double confirm" which was broken do not happen as easily. The real fix was bug 1043310 though. For 31.4.0 you can still sett this if you use the suitable combination of keyboard navigation in the autocomplete results.
Whiteboard: [serious, unobvious violation of privacy; everyday regular usage] → [fixed by bug 1043310]
Target Milestone: --- → Thunderbird 37.0
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
No longer blocks: 1089711
I have tried Thunderbird 31.4.0 and this problem seems to be resolved - good. Also the "feature" of a good selected email address being often displayed in red when selecting and adding to the "To" of a message being written seems to be fixed - again good stuff. But I cannot see any mention of this in the release notes page https://www.mozilla.org/en-US/thunderbird/31.4.0/releasenotes/ Also: Thunderbird Setup 31.3.0.exe - 25,862KB Thunderbird Setup 31.4.0.exe - 28,230KB The large increase in size makes me think that this is not just a bug-fix release, but that there is a whole bunch of new infrastructure/libraries or whatever in 31.4.0. I thought that the Thunderbird release system was like the Firefox ESR - 31.* is for security and essential (e.g. this privacy-related) fixes? I realise that an individual bug is not the place to discuss all this. Is there a Thunderbird email list for "ESR"/corporate issues, like the Firefox one?
Sorry, I found where to singup for the Thunderbird Enterprise mailing list: https://www.mozilla.org/en-US/thunderbird/organizations/ and to quote from the signup page: The Thunderbird Extended Support Releases (ESR) have now been merged into the mainstream releases. The mainstream releases are now operating to similar standards as the Mozilla Firefox ESR - they are stable for approximately one year, before receiving feature updates.
(In reply to Phil Davis from comment #47) > The large increase in size makes me think that this is not just a bug-fix > release, but that there is a whole bunch of new infrastructure/libraries or > whatever in 31.4.0. I thought that the Thunderbird release system was like > the Firefox ESR - 31.* is for security and essential (e.g. this > privacy-related) fixes? It is, there was one security bug affecting that required some more significant changes (the jp mac issue). The "red" address issue is not fixed though - bug 1042561.
(In reply to Phil Davis from comment #48) > Sorry, I found where to singup for the Thunderbird Enterprise mailing list: > https://www.mozilla.org/en-US/thunderbird/organizations/ > To quote again, from the signup page: "A community-lead project that allows organizations to benefit from the speed, flexibility and security of Thunderbird while getting the support they need." Don't they mean "community-led"? (Typo is in big italics.)
(In reply to Magnus Melin from comment #49) > It is, there was one security bug affecting that required some more > significant changes (the jp mac issue). The "red" address issue is not fixed > though - bug 1042561. Thanks for explaining this Magnus - it is good to know that there is a genuine reason for the much larger size installer.
This still happens when I choose an auto complete item by the right arrow key instead of mouse click. So I've filed it as a new bug 1123532.
Magnus, is this something we should take in esr31?
It's fixed by bug 1043310, and this fix landed for esr31 (see comment 51 in the other bug)
I am using 31.5 and am experiencing the same (or very similar) bug. C
I am using 31.5.0 The bug was improved but NOT completely fixed. If I address an email using autocomplete by typing in enough of the name until the name I want is in the address area... then, hit Enter, it will oftentimes change to another name with a similar text string. (e.g.: "Ann" "Hoffmann")
Agree this is NOT fixed, we also have this problem in 31.5.0 Nearly resulted in sending confidential information to the wrong recipient. Recipient's address changes when clicking into the body text section.
This bug is fixed. If you have a similar problem, file it as a new bug with clear steps to reproduce.
We use thunderbird 31.6.0, the problem still exist in special way: have a adress like 'dow@john.com' and a addressbook entry like 'dowes >> dowes@jones@com. I could reproduce the bug under windows and linux.
Not fixed at all, still experience the same problems at several computers, went back to 24.7 http://download.cdn.mozilla.net/pub/mozilla.org/thunderbird/releases/24.7.0/win32/
frogsfarms, pls understand that this is a bug database and not a release notes document. We have fixed this bug in the source code (aka "Trunk" -> Thunderbird Daily), from where it will bubble up into the next release, which is TB 38. It is not helpful to say "this bug is not fixed" without saying which version you are talking about. What we are saying here so far is that it IS fixed on Trunk (from where we build Thunderbird Daily) and on the release channel, it WILL be fixed on TB 38. We can't backport all the bug fixes into the current version of the release channel because that would expose you to more bugs and side effects possibly introduced by the bug fixes. So the normal procedure is to let the fix bubble up through several stages of testing before delivering it in the release channel product.
No longer blocks: 1043310
Depends on: 1043310
Keywords: privacy
Whiteboard: [fixed by bug 1043310] → [fixed for TB 38 by bug 1043310]
(In reply to Thomas D. from comment #61) Please scrap my comment 61, sorry I was mislead by frogsfarms' FALSE claim that this was not fixed (in release version of TB 31.x), and I jumped to wrong conclusions concerning the release for which bug 1043310 was fixed, which fixed this bug 1107844 in the process. Per bug 1043310 comment 53 and bug 1043310 comment 71, confirmed by user feedback in bug 1043310 comment 67, and verified by me (TB 31.6), bug 1043310 has been fixed for TB 31.5. It follows that this bug 1107844 (exactly as described in comment 0) has also been fixed for TB 31.5, which I just verified for TB 31.6.0 on win 8.1. Frogsfarms, pls stop making false claims that fixed bugs aren't fixed. In terms of bug management, a particular bug is fixed when it can no longer be reproduced by following exactly the steps described in the description of the bug (steps to reproduce, STR) and when the expected result happens instead, unless we've changed our expectations ;) For any other variants of the general problem "autocomplete does the wrong thing", even with only slightly different steps, please file NEW BUGS with detailed steps, actual result, and expected result.
Status: RESOLVED → VERIFIED
Whiteboard: [fixed for TB 38 by bug 1043310] → [fixed for TB 31.5 by bug 1043310, per comment 62]
Something similar which we still need to fix is bug 1152517!
See Also: → 1152517
Whiteboard: [fixed for TB 31.5 by bug 1043310, per comment 62] → [fixed for TB 31.5 by bug 1043310, per comment 62][see bug
Whiteboard: [fixed for TB 31.5 by bug 1043310, per comment 62][see bug → [No me-too's, see similar bug 1152517, or open new bug][FIXED for TB 31.5 by bug 1043310, per comment 62]
You need to log in before you can comment on or make changes to this bug.