260564 - automatically go to next line when selecting a recipient in the autocomplete list in the "to:" field

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, enhancement)

Description

[ant1]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3

It would be very nice for thunderbird to automatically go to the next recipient
line when a recipient is selected with a mouse left click in the drop down
autocomplete list of a "to:" field (instead of having to click on the next empty
line).
This would make thunderbird behave like outlook 2003 who automatically puts a
semi-colon after a recipient is selected in the autocomplete list, and all you
have to do is start typing the first letters of the next recipient etc..

It is a precious time saving feature, makes it very fast to send a mail to
multiple recipients.. 

Of course it is not a problem if you select the recipient in the autocomplete
list with the keyboard, and use return to validate (in that case it
automatically goes to the next line),
But a lot of people use the mouse...

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Wayne Mery (:wsmwk)]

(In reply to comment #0)
>..
> 
> Of course it is not a problem if you select the recipient in the autocomplete
> list with the keyboard, and use return to validate (in that case it
> automatically goes to the next line),

even though there is a noticable delay after hitting the enter key.

Comment 2

[Wayne Mery (:wsmwk)]

David, where would one start to impliment this?

Comment 3

[David :Bienvenu]

probably the addressing widget - I hope not the autocomplete.xml code...but I don't know.

Comment 4

[Thomas D. (:thomas8)]

The workflow underlying this bug is somewhat clumsy (hence potentially rare? certainly not recommended!):

Type search phrase for first recipient (keyboard)
Select from autocomplete results list (mouse; keyboard is certainly more efficient here...)
Type search phrase for next recipient (keyboard)

But for avid mouse users it's a legitimate and possible scenario causing unnecessary inefficiency. In those cases, it would really be helpful and ux-consistent with choosing result by keyboard. This should be easy to fix, confirm the recipient on mouse-click in results list and go to next row as we do for keyboard confirmation with Enter or Tab.

This bug in it's current form will be obsoleted by bug 440377, but until that really lands, this could be fixed anyway.

Comment 5

[rishabh]

hello, I want to contribute to thunderbird. I have built it on my system and currently looking up the list of good first bugs. Bug id:260564 interests me. Wanted to know about its status and would like to work on it.

Comment 6

[Magnus Melin [:mkmelin]]

Eh, actually, in 31 we do this already.
Whether we should or not (for tab) is discussed in bug 1043784. The patch there reverses this case too - if we want to split the cases autocomplete.xml should set mEnterEvent for handleTab() too, and the patch in bug 1043784 should check enterEvent.key.

rishabh: glad to hear you want to contribute. This might not be the best bug to start atm though... 
(bugzilla autolinks bugnumbers if you prefix the number with "bug ")

Comment 7

[Alessandro Castellani [:aleca]]

I think this was fixed by bug 1580950, right?

Comment 8

[Jorg K (CEST = GMT+2)]

I think if you review a bunch of old bugs, you'll find that a fair share of them is fixed now and no one bothered to go back and close them.

As far as I can think of, clicking an auto-complete result always selected it and moved to the next line. Sure, that broke in recent de-XBL activities, and was re-established in bug 1580950 (bug description: "no longer"), so certainly bug 1580950 didn't fix this bug here.

So since we don't know when exactly this was implemented between 2004 and 2014, I can just close this as WFM.

Most likely it was fixed in TB 31 when switching from XPFE auto-complete to toolkit auto-complete in bug 959209.