Closed Bug 1140942 Opened 10 years ago Closed 9 years ago

Auto complete completes even if no recipient selected.

Categories

(Thunderbird :: Message Compose Window, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1152517

People

(Reporter: unicorn.consulting, Unassigned)

Details

(Keywords: regression)

Steps to reproduce. Start Typing in the address fields Mouse over the addresses listed on the way to say the text compose, or to select an entry in the address pane Result The last entry in the list the mouse actually highlights will appear in the address field even though nothing was expressly selected. Expected Result The addess field would remain blank as nothing was expressly selected.
Version 31.2 which I have installed is not affected. Reporter in SUMO says 31.5 affected https://support.mozilla.org/en-US/questions/1050448 Magnus, could this be a by blow of bug 1043310
Flags: needinfo?(mkmelin+mozilla)
Keywords: regression
Kind of yes - before that we would not change what was in the input field (but that is often not the desired value wrt capitalization, ">>>" etc). The choice of what address to complete to when there's no explicit choice is not always clear. I agree though that after mousing out of the selections the last entry should no longer be selected.
Flags: needinfo?(mkmelin+mozilla)
(In reply to Magnus Melin from comment #2) > Kind of yes - before that we would not change what was in the input field > (but that is often not the desired value wrt capitalization, ">>>" etc). > The choice of what address to complete to when there's no explicit choice is > not always clear. Writing up exact documentation for such things might help us to understand the various scenarios and their pitfalls better... I think the following is just tolerable: If the user does not delete the suggested, highlighted part of the best match in the input field (with or without >>), we consider that an implicit consent to that suggestion. However, I find it very unacceptable that after user explicitly deletes the suggested part, then clicks with mouse somewhere else (without hovering over results list), we stubbornly restore the best match which user has just explicitly rejected by deleting the suggested completion. We may or may not already have a bug for that, around force-complete. But the following is much worse (and much more frequent): > I agree though that after mousing out of the selections > the last entry should no longer be selected. Yes, the last-hovered entry of results list is completely accidental and definitely not the intended recipient. So we're swapping the chosen recipient against a random other recipient. It's completely random from a users point of view (albeit technically, we know how it happens). Which is dataloss and violating privacy. I'll forward-duplicate this to bug 1152517 which has better description, STR, and screenshot.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.