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)
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
Comment 2•10 years ago
|
||
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)
Comment 3•9 years ago
|
||
(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.
Description
•