Closed Bug 260564 Opened 16 years ago Closed 10 months ago

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

Categories

(Thunderbird :: Message Compose Window, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: ant1box, Unassigned)

References

Details

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.
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
David, where would one start to impliment this?
probably the addressing widget - I hope not the autocomplete.xml code...but I don't know.
QA Contact: message-compose
Assignee: mscott → nobody
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.
Depends on: 440377
OS: Windows XP → All
Hardware: x86 → All
Whiteboard: [good first bug]
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.
Flags: needinfo?(nobody)
Flags: needinfo?(nobody) → needinfo?(mkmelin+mozilla)
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 ")
Flags: needinfo?(mkmelin+mozilla)
Whiteboard: [good first bug]
No longer blocks: 1106457

I think this was fixed by bug 1580950, right?

Flags: needinfo?(jorgk)

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.

Status: NEW → RESOLVED
Closed: 10 months ago
Flags: needinfo?(jorgk)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.