Closed Bug 1184050 Opened 4 years ago Closed 4 years ago

Recipient e-mail addresses changed without positive user intervention


(Thunderbird :: Message Compose Window, defect)

38 Branch
Not set


(Not tracked)



(Reporter: rob, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

Type in the first few letters of an e-mail address until the desired address appears and then move the mouse pointer to another location on the screen in such a way that it traverses the drop-down box containing other suggested e-mail addresses.

Actual results:

The address appears in the recipient field (to, cc, bcc) but if one moves the mouse over the drop-down box of possible other e-mail addresses, it automatically sets the recipient e-mail to the address which was under the mouse pointer at the time the pointer moved off the drop-down box. The user is not notified of this change and is unlikely to notice since their gaze will be rapidly following the mouse pointer to the next operation or waiting for the pointer to transition to that point.

Expected results:

Once a suggested recipient e-mail address appears in a recipient box, the recipient e-mail address should not change without positive user input (eg. mouse click, tab away from the recipient field, pressing Enter key).

This is a critical error because it makes it very easy for an e-mail to be sent to the wrong address without the user being aware. And let's be honest, when we see the correct e-mail in the recipient field (at the top of the list in the drop-down box) we tend to presume it will stay that way until we actively change it, because that's how it works in all major mail clients and how it used to work in Thunderbird.

This error has happened to us several times and I have instructed our staff to cease using Thunderbird until it is resolved, because a confidential proposal was accidentally sent to a person who should definitely not have seen it. 

This error was not present prior to approximately V24, but has consistently been present ever since.
BTW, I've checked all the bug reports dealing with similar issues and they don't seem to describe precisely what I'm reporting, so please give me feedback before marking this as a duplicate.
Rob, thanks for reporting and taking time to look at the other bug reports!

This does look very precisely like a duplicate of Bug 1152517, no?
Whiteboard: [dupeme after confirmation from reporter]
(In reply to Thomas D. from comment #2)
> Rob, thanks for reporting and taking time to look at the other bug reports!
> This does look very precisely like a duplicate of Bug 1152517, no?

I admit that I read that bug report but it seemed to be describing somewhat different behaviour and it could do with some clarification. But yes, if the same issue is being addressed by the Mozilla team, then that's all good and my report is obviously a duplicate and can be marked closed. Thanks.
Thanks for swift reply...
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1152517
Whiteboard: [dupeme after confirmation from reporter]
You need to log in before you can comment on or make changes to this bug.