+++ This bug was initially created as a clone of Bug #1003856 +++ For recipient autocomplete, when you get inline suggestion like "foo >> somefoo <mail@asdf.com>", using TAB with an intention of accepting the suggestion and proceeding to subject field used to work (TB24), but fails now (regression). STR 1 contact having "somefoo" in any field searched by autocomplete (e.g. First Name) 2 compose msg, type "foo" into recipient input (where "foo" should *not* match anything at the *beginning* of searched fields, this only happens for "contains" matches) -> so you'll get suggestion "foo >> somefoo <mail@asdf.com>" 3a Press [Tab] on keyboard 3b another variant: start again from step 2 - don't touch the suggestion - focus another window, then refocus composition - press enter on suggestion 3c for comparison: start again from step 2, then press [Enter] on suggestion Actual Result 3a) Pressing [tab] on suggestion with angle brackets does *not* confirm the suggestion on Trunk (however, we've always used [tab] for confirming as still seen in TB24 release -> regression); - suggestion with searchword and angle brackets is left behind and very hard to fix after that short of retyping - focus correctly moves to subject 3b) Another variant: Moving focus away from TB and back without touching the suggestion will make the suggestion become unresponsive: no autocomplete dropdown, [Enter] no longer confirms suggestion (bug) 3c) for comparison, [Enter] on suggestion shows expected behaviour wrt confirming the suggestion Expected Result 3a) [tab] should confirm suggestion (just like [Enter]), as in TB24 (imo users won't forgive that regression, hence dogfood - why would you press [tab] when you're not yet done with the current recipient?) 3b) Upon temporary loss of focus to another application, while recipient input with suggestion has focus, we should either: - preserve the UI status exactly, i.e. not change the behaviour of confirming the suggestion in any way, so pressing [enter] or [tab] on suggestion after returning focus to composition window should still work OR - confirm the suggestion (?) Confirming the suggestion when recipient input or TB window loses focus would simplify the behaviour a lot and probably fix bug 348844, bug 632127, and bug 749923 in one sweep. However, I'm not entirely sure if we can do that for cases where just *TB* as an application loses focus; it's certainly possible for cases where focus is deliberately moved to somewhere else *inside* TB's composition window as seen in those bugs (similar to the [tab] case). So I think my recommendation is: - if user focuses anything else *inside* composition, take that as confirmation of the suggestion - if TB composition loses focus to another application, preserve the exact focus, state and behaviour of autocompletion as before the loss of focus.

Sorry, wrong summary from cloning.

Unless verified otherwise, I assume TB31 is also affected by this, and should be fixed because - it's very exposed - really odd to revert when it happens; bad recipient when unnoticed and sent -> will be highly annoying to users

Note that FF bookmark tags autocompletion implemented another use of [tab]: - typing "f" will inline-autocomplete to tag "f[oo]" - pressing [tab] will cycle all the other matching tags from autocomplete dropdown I'm not sure if that's hig/UX-consistent and desirable behaviour; I'd rather expect something like first [tab] to do the autocompletion, second [tab] to move out of the field. For TB, I'd suggest we remain with the legacy behaviour where first [tab] on suggestion confirms it *and* moves on to subject field. Which looks like simple and intuitive behaviour to me.

Thanks Mark (:standard8) for immediate attention and feedback. Perhaps Magnus could fix this?

(In reply to Thomas D. from comment #6) > Thanks Mark (:standard8) for immediate attention and feedback. > Perhaps Magnus could fix this? Magnus, you have successfully fixed Bug 1003856 of which this is a remainder (almost same issue). It's in same category of disturbance and has tracking-thunderbird31+. Perhaps you could fix this?

Yes, I have a patch that fixes this (just needs finishing up).

(In reply to Magnus Melin from comment #8) > Yes, I have a patch that fixes this (just needs finishing up). would be good to get this in beta 2, but will need baking first

typing in "arnts" results in what you see in the attachment. It seems to scroll uo out of sight and apparently is thrown out on send or send later.

My patch in bug 1012398 fixes this, review pending.

Fixed by bug 1012398.

This should be fixed now in the latest daily, but I still see this issue. I've tested with 33.0a1 (2014-07-17) Build ID 20140717030251 with and without safe-mode on Mac OS X 10.9.4. I've used the STR from: https://bugzilla.mozilla.org/show_bug.cgi?id=966053#c20 And sadly I still see this ">>" issue like before.

With my Ubuntu 14.04 system Thunderbird upgraded with 31.0 version. When I compose a new e-mail message and typing an address with available the address book, after TAB or SHIFT+TAB key press Thunderbird presenting a new empty to: edit box. With previous Thunderbird 24.x version after correct autocompleted the typed search match, when TAB key press happening, the caret jumps right the Subject field. If the autocompletion happened right in Thunderbird 24.x version, when I pressed shift+tab keystroke, the caret jumps back correctly the awailable combo box with possible setting to, CC address type. Now, in Thunderbird 31.0 I need doing following to the caret lands the subject text box: 1. Type the search term, and the result is autocompleted. 2. Press a TAB key, and press backspace key to hide the empty to: field. 3. Press TAB key again to jump the subject field. The issue with I expected the 31.0 version not happening if I press ALT+S letter to jump the subject field. If anybody not known this mnemonic letter the subject: widget, need doing I described steps to remove the empty to: text box. If this is the expected result with I experienced in Thunderbird 31.0, possible toggling off this working method to restore the previous working method? If I filled previous the autocompleted e-mail address and want perhaps adding a new address, simple enough to press an ENTER key. Attila

There's no need to remove the empty To box, so all you need to do is press tab one more time than before. Anyway, it's not this bug, so file a new one if you want to discuss it further.

(In reply to Attila Hammer from comment #16) +1 for Windows 7. Tab adds extra To:-line; Shift+Tab moves forward instead of back. If someone does file a new bug on this regression, please post the bug number here. Thanks.

I filed bug 1043784 this problem related. Attila

This bug seems basically fixed (selected and confirmed address is taken over correctly), but the process of cursoring down in the dropdown list of results feels and behaves really wrong, as in screenshot attachment 8421621 [details]: - it's not right that 2 areas have blue background i.e. active focus at the same time - if I press Enter, will TB confirm the main one or the selection from the list? No way of telling - when users cursor down dropdown results list, something must visually change in the main recipient line: - at least blue background should become light-grey, to indicate de-focusing - the original suggestion could be removed? - the currently selected result could appear in the main row, probably behind the >> ? I haven't reflected on correct behaviour much, but the current behaviour feels very odd and non-responsive. Comments?

Yes it's kind of an odd state, because both can get input. I'd like to use tabscrolling for trunk and going forwards, that should fix a bunch of problems. (E.g. like the url bar: when multiple choces tab just moves selection to the next entry down in the list, enter confirms.) Anyway, this bug is closed, so lets not discuss it further here.

Although this was seemingly fixed in TB31, it seems mostly resolved in 32b1. Mostly. I can still repro the issue of "foo >> somefoo <mail@asdf.com>" when I type a name and then click the mouse anywhere in TB. I am doing the same STR: allowing autocomplete to suggest the name(s) and then click the mouse (left or right, doesn't matter). Should I open a new bug for this?

That's bug 1043310.