+++ This bug was initially created as a clone of Bug #486501 +++ edit an address after autocomplete and autocomplete reselects the first choice 0. Prepare scenario: - set mail.identity.default.autocompleteToMyDomain=true - have these addresses: foo1bar <foo1bar@asdf.com> (hightest popularity index, appearing topmost after searchword@mydomain suggestion in autocomplete results) foo2 <foo2@222.net> 1. compose 2. type "foo", i.e. something to get an autocomplete results list with more than 2 results (including the searchword@mydomain suggestion!) 3. pick "foo2 <foo2@222.net>", i.e. the 3rd result (or any other below that) using mouse or keyboard 4. Correct/alter and confirm 3rd address *at rapid speed* without pause (important!): E.g. on foo2 <foo2@222.net>, rapidly: - Cursor left: foo2 <foo2@222.net|> (where | = cursor) - Backspace: foo2 <foo2@222.ne> (final t now deleted) - Enter Actual results: (Only if you did step 4 fast enough!) Bug: TB replaces the corrected, valid recipient address with a completely unrelated address, namely the initial/first/topmost autocomplete match from AB (except the generated searchwords@mydomain.com) (If you are too slow at step 4, TB will accept corrected address as-is.) Expected results: TB should *never* (under no circumstances) interfere with recipients defined by user, much less substitute an unrelated recipient, but just accept the corrected/altered recipient address

(In reply to Thomas D. from comment #0) > Actual results: > > (Only if you did step 4 fast enough!) Bug: TB replaces the corrected, valid > recipient address with a completely unrelated address, namely the > initial/first/topmost autocomplete match from AB (except the generated > searchwords@mydomain.com) So in the example of comment 0, TB unwarrantedly replaces ´foo2 <foo2@222.ne>´ (recipient defined by user) with ´foo1bar <foo1bar@asdf.com>´ (first match from AB). Even if the corrected version is a known AB entry (delete the final t and put it back + Enter quickly). > (If you are too slow at step 4, TB will accept corrected address as-is.) > > Expected results: > > TB should *never* (under no circumstances) interfere with recipients defined > by user, much less substitute an unrelated recipient, but just accept the > corrected/altered recipient address TB should keep the corrected address as-is, i.e. foo2 <foo2@222.ne> (sic)

Magnus: does your patch in bug 1012398 fix this as well? Gerv

I don't think so, but it seems i can't reproduce it either.

Magnus: let me give you some simpler steps to reproduce (I am using TB 31 beta on Ubuntu 14.04): * Create new compose message * Type something with multiple matches in the address book, e.g. "Adam" * Press "Down Arrow" a couple of times to select the third entry (for example) * Press Tab Expected: focus changes to Subject, and third entry is populated in To field Actual: focus changes to Subject, and first entry is populated in To field Gerv

Yes, that part is works fine with my patch applied.

I I can confirm Gervase's bug as described in comment #4 above is still there in Version 31 on OSX (i.e. its not specific to Windows XP as suggested in the summary) . I think this is newly bad behavior. I'm not sure if Magnus's patch is there in V31.

My bug from comment #4 is fixed in version 31 final on Ubuntu 14.04. Gerv

There is still a bug here, in Thunderbird 31.0 Final, as now shipped to Ubuntu 14.04, which causes the wrong address to be selected. We need to fix this quickly, otherwise we are going to embarrass a lot of users! STR (in both 31 and 32): * Start new message * Type "Adam" or some other string with multiple matches * Down Arrow to select the second one * Tab to choose it. Address selected is displayed. * Enter to go to next line to input another address. Address selected in previous line changes to the first hit from the search! It's easy not to notice, and it could have very bad consequences! Gerv

It already has Gervase, I've sent several emails to the wrong people because of this bug.

Me and my users have also been affected by this bug - sending e-mail to unintended recipients is serious.

Video showing the problem in Windows, TB 34 beta 1: Down-arrow, click, return. The clicked address gets changed to something else. This is BAD!!

Jorg K: that was ultimately fixed in bug 1043310. For thunderbird 31.4.0 "wrong selection" (bug 1107844) is now a lot less prominent since bug 1043784 was backed out. As for this bug it should be fixed by bug 1043310 too. Thomas D: are you able to verify?

Sorry, my video should perhaps go to bug 1107844. I got confused by comment #8. There they talk about hitting enter.

No problem, there were a lot of semi-related issues relating to that.

What about the original bug 486501 (see "User Story", 1st line)? Is that fixed by bug 1043310 as well?

Yes, that's working now. If you're able, do help verify everything's ok with nightlies.