edit an address after autocomplete and autocomplete reselects the first choice 1. compose 2. type something to get an autocomplete list >1 3. pick the second choice 4. edit 5. tab or click away expected results: editted results stick actual results: first address in autocomplete list is substituted

note: step 3 is key. I just tested version 2 and can't reproduce there, so a regression. In v2, the address just goes red. might this get fixed by bug 360648 toolkit autocomplete? But 360648 might not make TB v3 (it's only wanted+), so requesting blocking+ or wanted+ for this bug

We can't repro. Can you still? What OS? Denying blocking as 4 of us can't repro, but if would reconsider if we can =).

I cannot reproduce on my vista machine. I can reproduce on my XP machine. The differences are, besides build#, XP has ldap lookup, and the name portion of addresses I tested on XP are surrounded by "" because of included () chars. I've determined the problem is the later. 1. create 2 ab entries "David Bienvenu (who?)" <bienvenu@davidbienvenu.org> "Dan Mosedale (TB Mac)" <dmose@mozilla.org> i.e. display name David Bienvenu (who?) and Dan Mosedale (TB Mac) respectively 2.

[premature commit] so, better steps 1. create 2 ab entries "David Bienvenu (who?)" <bienvenu@davidbienvenu.org> "Dan Mosedale (TB Mac)" <dmose@mozilla.org> i.e. display name David Bienvenu (who?) and Dan Mosedale (TB Mac) respectively 2. compose new message, type "da" in To: field 3. pick the second address offered 4. change any character in the address or name and hit return/enter results: reverts to first address offered by autocomplete not 100% sure if both addresses must have "", but I tested where both autocomplete offerings are without "" and I can't recreate the problem. If first display name doesn't have () and second one does (and autocompletes with ""), then Ido see the problem.

Tony, do you see this in Seamonkey? I still see it. perhaps related to Bug 418192 ?

Confirming for Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 omg, this is really nasty. do steps exactly as in wayne's comment 4 and thunderbird will stubbornly ignore any manual correction and mess up your recipients as it pleases to. addendum to step 4 of comment 4 After correcting any letter in the 2nd address, even just pressing cursor keys inside the 2nd address will autocomplete to the 1st address, iow in the above example it will send the message to david instead of dan! Iow, through normal user interaction the email can be involuntary misdirected to a completely unrelated recipient -> privacy! Furthermore, the fact that an email application changes recipients at will and against the user's correct interaction with the UI doesn't look like a normal bug to me -> this should be "major" -> imho, this should block.

dupe of Bug 131692?

bugzilla is currently in the habit of deleting dependencies magically, wasn't me!

I can still reproduce this following exactly steps of Wayne's comment 4 on TB17,winxp. In the worst case, this re-selects recipients which are totally unrelated to the chosen recipient (violation of privacy -> major; see comment 6) Basically, this means that if you pick any address known in your AB from autocomplete which happens to have quotes in the display name ("John Doe" <john@office.com>), there is absolutely no way you can manually correct or alter that address in the recipient field (e.g. to become "John Doe-Miller" <john@private.com>), TB will stubbornly revert your changes to the autocompleted address, annihilating any of your corrections as soon as you press cursor key, Enter, or Tab. This is absolutely weird in terms of ux-trust. Try this STR variant: 1 have display name: "John Doe" (with quotes); email: <john@office.com> in your AB (suppose that's john's address at work) 2 compose msg, type "john doe" without quotes, autocomplete with Enter or tab to his address 3 realize you want to write to his private address not yet in your AB: copy the string "john@private.com" without quotes into clipboard 4 in recipient pane, select (highlight) string "office.com" from john's address 5 Ctrl+V to paste and overwrite "office.com" with "private.com" (just that, don't touch anything else) 6 single-left-click straight into msg body pane 7 note email address shown in recipient pane 8 click into, or tab in and out, or focus and cursor in john's (corrected) address Actual result: 7 95% of my testcases, the corrected address appears to remain in recipient pane if you don't touch it after pasting but just click somewhere else straight, so you see (correctly) john@private.com 8 if you touch the corrected address in any way, even just click, it will suddenly revert back to john@office.com (and worse, as in scenario of this bug, it might even revert to another person's address!) -> privacy, ux-error-prevention Expected result: TB should never unwarrantedly mess around with my addresses and alter them randomly TB should just accept and preserve whichever address I currently have in the box (ux-wysiwyg), unless and until I deliberately select another address! Per David Ascher's comment 2, this should be considered for blocking if reproducible which is the case. Wayne also suggested blocking+ on comment1. Messing around with user's addresses and privacy is certainly a qualified reason to block the release of a mailer, at least for the next release after TB24 (which is about to be released in a couple of days).

major per comment 6, comment 10, violating privacy, and other ux-flags

Wild guess for cause of problem: Maybe what happens here is that when you get the first autocomplete suggestion, it is saved in index=-1 of the autocomplete list. Then you choose your address, any index. When you correct that address, and the corrected variant is not found in AB, that resets the index to -1, which in turn reverts to the old address remembered for index=-1, but shouldn't.

It's inconvenient but I work around it by not putting text in display name that I don't want the world to see in my mail.

Whilst this is significant, I don't see anything having changed recently to make this worse or to need tracking. I would also suggest retesting on something that's 25 or later, as we've changed some of the autocomplete mechanism. That said, this could be somewhere in the xpfe autocomplete code, so Neil might have a better idea of where the error or possible fix lies.

I'm 100% sure having reproduced this on TB24 just now (more than once) on names *without quotes*, where the second result was an email-address without display name, but it's erratic and now I can't reproduce any more. Might involve number of open compose window, or if it's the first mail composed in a session, or something strange like that.

What a can of worms (on TB24)... This bug has morphed somewhat, new STR are in comment 4 and require quoted display names: Occurs easily, always reproducable regardless of interaction speed. So that's the worse variant of this. But I also found unquoted case (bit harder to run into): (In reply to Thomas D. from comment #15) > I'm 100% sure having reproduced this on TB24 just now (more than once) on > names *without quotes*, where the second result was an email-address without > display name, but it's erratic and now I can't reproduce any more. Might > involve number of open compose window, or if it's the first mail composed in > a session, or something strange like that. That scenario requires - mail.identity.default.autocompleteToMyDomain=true - rapid correction and confirmation without pause --> Filed as bug 1025684.

I've had four important emails (that I know of) sent to the wrong person now, after having been completely certain that I had selected the right one from the list. At first, I thought I had been making a mistake, and so took extra care to really make sure that the correct email address was being selected from the autocomplete list, but it kept happening. Finally, I realised that this was a bug in Thunderbird, rather than my own fault. It appears that this report should probably be filed here. If you think that it is not this exact bug, and needs to be filed separately, then please let me know. Normally, Thunderbird works like this: Compose a new email. In the first To: field, start typing the first few characters of email address. A drop-down list of possible completions is provided. You move down the list (for example, with the cursor keys) and select one (with enter or tab, for example) and the cursor moves on to the next blank field, having populated the field with the email address selected. However, sometimes this happens: Compose a new email. In the first To: field, start typing the first few characters of email address. A drop-down list of possible completions is provided. You move down the list (for example, with the cursor keys) and select one using cursor right (or left). The field is populated with the email address you selected, enabling you to verify that you have really chosen the correct one (and even allowing you to edit it if you like). When you're done, you move to the next field (with enter or tab, for example, as before). When you do this, Thunderbird surreptitiously and without warning replaces the email address you had selected and verified with the email address that happened to be first in the autocomplete list that was shown a while ago. Since the email address Thunderbird has used starts with the same characters as the one you wanted, and the looks similar (for example, the person has the same first name), you don't notice that Thunderbird has switched the email addresses and send the email anyway and disaster ensues. With Thunderbird 31.2.0 on Ubuntu, this is entirely reproducible. Please fix!

I'm running 31.3.0 and can confirm that this behavior is fully reproducible on my system. While I'd also argue that the order of selection is wrong (but a different problem), it's a far-larger problem that one can make a selection made from a drop-down list and have it retroactively changed by hitting tab or enter. I carefully type a few characters, get a list of candidates, pick one, and then Thunderbird changes it back to the first email addresses in the list as I hit enter. This is a serious problem with very embarrassing results. I now need to dig my way our of a major hole that I've created by sending a very important email to the wrong destination.

(In reply to Roger Ronald from comment #18) > I'm running 31.3.0 and can confirm that this behavior is fully reproducible > on my system. > > While I'd also argue that the order of selection is wrong (but a different > problem), it's a far-larger problem that one can make a selection made from > a drop-down list and have it retroactively changed by hitting tab or enter. > I carefully type a few characters, get a list of candidates, pick one, and > then Thunderbird changes it back to the first email addresses in the list as > I hit enter. That's Bug 1107844. This bug here is similar but only about manually correcting addresses, plus involving quoted display names. > This is a serious problem with very embarrassing results. I now need to dig > my way our of a major hole that I've created by sending a very important > email to the wrong destination. Bug 1107844 is indeed a very serious problem, and I've tried to express that in clear terms on the bug and also get some of the right people on board who might be able to look into this.

It's a HUGE "problem that one can make a selection made from a drop-down list and have it retroactively changed by hitting tab or enter." Like Roger Ronald, "I'm running 31.3.0 and can confirm that this behavior is fully reproducible on my system." ***It even happens if you DON'T edit the address that you've selected.*** Adding the words "tab" and "enter" to the problem description would be helpful here so that others can find this thread. The TAB or ENTER key should not nullify a user's previous affirmative selection of a recipient.

WFM now. Should be bug 1043310 that fixed it.

Well, it's fixed to the extent that it still reverts to the address book entry if what's in the box is a substring of the entry. But it doesn't revert to a different address.

(In reply to Magnus Melin from comment #22) > Well, it's fixed to the extent that it still reverts to the address book > entry if what's in the box is a substring of the entry. But it doesn't > revert to a different address. This should be tested meticulously against the more precise STR of comment 6 and comment 10 to ensure it is really wfm/"fixed".

This bug is a very serious problem, and it keeps happening. I'm using version 31.7.0. Just now an email sent to a colleague with a complaint from a client, was inadvertently sent to a new potential customer in the process of making a decision about a $50,000 job! I am absolutely furious. The email it was sent to, with the same first name, is not even close to my colleague's name on the dropdown list. Because this has happened several times I also specifically double checked to ensure his address was the one I had selected. Yet, it still was sent to the wrong address, with potentially catastrophic effects. This may force me to move away from Thunderbird even though I've been using it for at least 10 years. So, this bug IS NOT FIXED!!!!!!! Please someone look at this and advise me what to do.

This should be fixed in the new TB 38 version as per comment #21 (surely it's not fixed in 31.7).

I'm running Thunderbird 38.3.0 and am having the same issue with the autocomplete. It's intermittent, but when it happens, it's exactly as described as above. It hasn't caused a serious issue to date, but it's only a matter of time until it does. Since this thread is labeled RESOLVED: FIXED, should I be opening a new bug report?

Yes, with detailed steps to reproduce.