Closed Bug 1187519 Opened 9 years ago Closed 9 years ago

Take Bug 1152517 "Recipient autocomplete wrongly considers last mouse-hovered contact ..." and Bug 1130858 "Recipient autocomplete suggestion overrides ANY manual address ..." into TB 38.x

Categories

(Thunderbird :: General, defect, P1)

Product:
Thunderbird
Component:
General
Version:
38 Branch
Type:
defect

Tracking

(thunderbird_esr3840+ fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
thunderbird_esr38 40+ fixed

People

(Reporter: jorgk-bmo, Unassigned)

References

Details

(Keywords: dataloss, privacy) 

+++ This bug was initially created as a clone of Bug #1152517 +++

As the summary says:
Take 
Bug 1152517 "Recipient autocomplete wrongly considers last mouse-hovered contact ..." and 
Bug 1130858 "Recipient autocomplete suggestion overrides ANY manual address ..."
into TB 38.x
Depends on: 1130858
Is this relevant to this bug?  Or another entirely?

I just noticed in Nightly that a manually edited address in the To field is auto replaced with the incorrect entry from the address book on the field loosing focus.

I sent a mail adding a period after the address.  It bounced for obvious reasons.  I clicked edit as new and edited the address.  On leaving the field the value was replaced with the original.

This behaviour continued until I removed the incorrect address entry from the collected address book.
Since you asked: What you wrote is not relevant at all ;-(
This bug is purely "internal" for release management, so we can track the "uplift" of two M-C changes from mozilla42 to a TB 38.x release.

The problem you're describing is bug 1138033. You cannot manually shorten an address, if a longer one exists in the address book. In your case the longer one is the incorrect one with the dot at the end.
(In reply to Jorg K from comment #2)
> Since you asked: What you wrote is not relevant at all ;-(
> The problem you're describing is bug 1138033. 

Thank you on both counts Jorg.  You covered my ineptitude concisely
Matt: Sorry, I didn't intend to sound harsh, hence the ";-(". It's very hard to know all the bugs.
Thank you for reporting your observation. You could add your case to bug 1138033 since it's an interesting new aspect (that an invalid address is overriding a manual correction).
(In reply to Jorg K from comment #4)
> Matt: Sorry, I didn't intend to sound harsh, hence the ";-(". It's very hard
> to know all the bugs.
> Thank you for reporting your observation. You could add your case to bug
> 1138033 since it's an interesting new aspect (that an invalid address is
> overriding a manual correction).

I have no issue.  I was genuinely please to be pointed in the right direction.  Will post on Bug 1138033.
Magnus, since we keep collecting duplicates at the corresponding toolkit bug 1152517, and were encouraged by rkent to land this asap, because it's so nasty, could you take this bug and port bug 1152517 to TB for early landing?
Flags: needinfo?(mkmelin+mozilla)
I don't think there's more to do than land.
Flags: needinfo?(mkmelin+mozilla)
Whiteboard: [dupetome][nasty simple variant: comment 15]
I'm not into trees and landings, so what's the next step to make this land asap?
Flags: needinfo?(mozilla)
Frankly, I don't know what Magnus is referring to (and IMHO it's also not helpful to speak in riddles).
The two M-C bugs have M-C patches. These patches need to be uplifted/landed on the ESR38 release branch.
Kent decides on that in consultation with the author of the patches, in this case Magnus. I think Kent is aware of the issue, but I can "need info" him again.

Kent, what is you're feeling on this?
Flags: needinfo?(mozilla) → needinfo?(rkent)
It would be helpful if someone could confirm that this patch has been tested on a nightly build, and it does indeed now behave better and as expected.
Flags: needinfo?(rkent)
(In reply to Kent James (:rkent) from comment #10)
> It would be helpful if someone could confirm that this patch has been tested
> on a nightly build, and it does indeed now behave better and as expected.

Is Daily 42.0a1 (2015-08-05) supposed to pick up the fix automatically from M-C?

Daily 42.0a1 (2015-08-05) still has the bug for all keyboard scenarios (tab, right-click, Enter), using the accidentally hovered/highlighted address from results list and NOT the autocompleted typed address.
Only clicking elsewhere will use the autocompleted typed address in spite of the hover-highlight.

OT: I've also recently seen a request to not autocomplete when TAB is used, because TAB is just supposed to move focus without changing user input. Maybe the same applies to cursor right. Something to think about. The behaviour of autocomplete is pretty geeky und still far from controllable given outstanding bugs.
(In reply to Thomas D. from comment #11)
> Daily 42.0a1 (2015-08-05) still has the bug for all keyboard scenarios

FTR, I tested with jane@asdf.com and john@asdf.com and typed "asdf" so it also involved getting the >> for autocompletion, in case that matters which it should not.
(In reply to Thomas D. from comment #11)
> Is Daily 42.0a1 (2015-08-05) supposed to pick up the fix automatically from
> M-C?
Sure. A TB Daily compiles with the state of C-C and M-C at that day/night.
BTW, Firefox calls their stuff Nightly since it compiles at night US time with the state of M-C at that time.

If the bug is still there, we need to refer the matter back to Magnus.
(In reply to Thomas D. from comment #11)
> Daily 42.0a1 (2015-08-05) still has the bug for all keyboard scenarios (tab,
> right-click, Enter), using the accidentally hovered/highlighted address from
> results list and NOT the autocompleted typed address.
> Only clicking elsewhere will use the autocompleted typed address in spite of
> the hover-highlight.

Thx for testing. I don't know what you mean though. Bug 1152517 is about mouse-hovering so how is other tab and other relevant?
If you meant mouse hovering over a suggestion and then hitting enter or tab to confirm, I don't think the preferred behavior for that isn't really clear. It may choose something you didn't necessarily want (or not). But it doesn't change an already confirmed suggestion AFAIK.
Bug 1152517, can be seen nicely in attachment 8589863 [details]. Can reproduce in TB 38.
Bug 1130858, tricky to reproduce, you need to confirm quickly, anyway, reproduced in TB 38.

Now tried Daily (42.0a1 (2015-08-07)):

Bug 1152517: I cannot reproduce this in this version. So I'd call it fixed.
  However: The hovered choice will be used on <tab> or <enter>. That works as designed.
Bug 1130858: As I said, it's hard to reproduce in the first place. I gave it a good shot in daily and cannot reproduce it. I went back to TB 38 (after practicing the movements to do them quickly) and there it happened every time. So I'd call this fixed as well.

Thank you, Magnus, this M-C autocomplete stuff is tricky, not to mention to get changes through a review.

Since these bugs seem to be much hated (although honestly I never experienced them myself), I'd ship the fixes. I hope that exhaustively answers Kent's request from comment #10: Confirmed working!!
(In reply to Jorg K (Thunderbird C-C contributions suspended) from comment #16)
> Bug 1152517, can be seen nicely in attachment 8589863 [details]. Can
> reproduce in TB 38.
> Bug 1130858, tricky to reproduce, you need to confirm quickly, anyway,
> reproduced in TB 38.
> 
> Now tried Daily (42.0a1 (2015-08-07)):
> 
> Bug 1152517: I cannot reproduce this in this version. So I'd call it fixed.
>   However: The hovered choice will be used on <tab> or <enter>. That works
> as designed.

As designed!? No...
Bug 1152517 is clearly NOT FIXED in its entirety. Only the worst scenario of bug 1152517 has been fixed.

Current summary of Bug 1152517 clearly includes using the hovered choice on <tab> or <enter> as bug scenarios:
> Recipient autocomplete wrongly considers last mouse-hovered contact from results dropdown "selected"
> and then uses that unintended, random recipient upon blur (via *Tab, Enter,* or when moving to subject
> or body)"

Bug 1152517 Comment 15 clearly describes why the hover & tab/Enter/cursor right scenario is a bug in terms of UX-error-prevention. In fact, the ambiguous situation of double-focus as seen in attachment 8589863 [details] (and still occuring in Daily) should never occur: Until the hovered selection is confirmed, we must use a lighter highlight color to differ between the dark-blue selection focus color; please compare Windows Explorer behaviour: When one file is *really* selected, and another just hovered, highlight colors differ, AND of course only the really selected file will open with ENTER and NOT the hovered file.
It's very easy for keyboard-only or mixed mouse/keyboard users to use keyboard and then accidentally move mouse one millimeter and cause a random unintended selection; otoh, it's very unlikely that after *intentionally* mouse-hovering over the small space of a contact from the list you'd then suddenly change over to using keyboard for confirmation while just left-clicking with the same mouse which you are still holding from the hover will do the trick.

> Since these bugs seem to be much hated (although honestly I never
> experienced them myself), I'd ship the fixes.

+1. I'd also ship the fix asap even though it's not complete yet.
But indeed these bugs are much hated as massive violations of privacy, which means we can't take any chances in terms of ux-error-prevention, so we must fix the remaining scenarios asap.

> I hope that exhaustively
> answers Kent's request from comment #10: Confirmed working!!

Unfortunately not.
Short summary of comment 17: Basic UX Design Principle: Focus takes keyboard input, and an application can only have a single focus at any time. In scenario of attachment 8589863 [details] the visual representations of keyboard-input-focus vs. mouse-hover are not distinguished, creating an ambiguous situation of apparent double focus. But last keyboard focus is clearly on the input field; just mouse-hovering can never change keyboard focus, so as long as user doesn't click anywhere else, keyboard focus must remain in the input field. Which is also required in terms of ux-error-prevention to guard against errors from accidental minimal mouse moves (see Bug 1152517 Comment 15).
Yes, you are correct in that the description of bug 1152517 mentioned losing focus via tab and enter.

However, I believe that tab and enter are *confirmatory* actions on a hovered choice, as is a mouse click. I agree that the indication of where the focus is and what will be confirmed is somewhat suboptimal. Perhaps that could be fixed with a style change. You could raise a bug along those lines.

In fairness I should remark that the URL autocomplete in FF does work more like you describe, there is less of a double focus problem: Enter an incomplete URL in Firefox (for example just www.): tab and up/down-arrow navigate through the menu and supply the value to the URL field. Hover also highlights the hovered choice, but enter confirms the "other" choice in the URL field, not what is hovered. So if we don't go for a style change as suggested in the previous paragraph, you should raise another bug along the lines of "Make autocomplete for recipient addresses work more like the FF URL autocomplete": Arrows and tab navigate through the menu and supply value, enter uses supplied value no matter what is hovered.

The following is irrelevant in the context of the UX discussion, but I'd like to mention it:

A keyboard-only user has absolutely no problem with the current state:
Option one: They type as much as is required to only have one auto-suggestion. Then they confirm with tab or enter.
Option two: They use the arrow keys to select what they want and then press tab or enter.

(I myself as a mixed user also have no problem: I type part of the address, if necessary, click to select (menu goes away!), tab/enter to confirm. I love it, the new autocomplete is great.)
Re. option 1: Style: Try
  .autocomplete-tree treechildren::-moz-tree-row(hover) {
   background-color: #ff8080 !important;
  }
(or any colour of your choice) in your userChrome.css

(I quite like it, I think I will keep that setting. I already use this colour to highlight the folder drop target when moving messages to a folder, so I don't accidentally hit the wrong folder.)
Correction!

Use
  .autocomplete-tree treechildren::-moz-tree-row(hover) {
    background-color: green !important;
  }
  .autocomplete-tree treechildren::-moz-tree-row(selected) {
    background-color: #ff8080 !important;
  }
If you use the arrow keys, you can get hover and selected in different colours.
Tab and enter select the *selected*, not the hovered row.
In the final setup you would of course lose the "hover" configuration.
Thanks a lot Jorg for rapid, informative, and constructive feedback including helpful hints for technical analysis.

(In reply to Jorg K (Thunderbird C-C contributions suspended) from comment #19)
> Yes, you are correct in that the description of bug 1152517 mentioned losing
> focus via tab and enter.
> 
> However, I believe that tab and enter are *confirmatory* actions on a
> hovered choice, as is a mouse click.

NO. You can only confirm with keyboard what's already selected. Just hovering under normal circumstances must never select something, more so in the privacy-sensitive recipient input area we're talking about. 

Selecting things with mouse typically requires an explicit click, because otherwise any (unrelated/accidental) mouse move would select/focus everything selectable/focusable along the way.
So Thunderbird translating even the slightest (unrelated/accidental) mouse move on the results list into a snap-selection is a bug (and Firefox behaves differently for good reasons). On top of that bug, there's the visual presentation and input value filling bug (again, Firefox has much better behaviour).

Also, for the case of pointing at a contact from the results list with the intention of using that contact, the most natural and practical way of selecting/confirming it is certainly not Enter or Tab, but just left-clicking with the mouse which you've just moved exactly to the right spot.
Snap-selecting things on hover also violates ux-consistency with other Mozilla applications and Windows OS, where afasik this behaviour is not found.

> I agree that the indication of where
> the focus is and what will be confirmed is somewhat suboptimal. Perhaps that
> could be fixed with a style change. You could raise a bug along those lines.

Style-change only will not be sufficient in terms of ux-error-prevention and even ux-efficiency. We have no way of telling if the hover is really intended to select another contact or if it's just an unrelated or even entirely accidental mouse move which happens to touch the result list. Hence Firefox expects you to either to confirm the hovered URL with left-click or to use keyboard cursor/tab to explicitly navigate the list before confirming the selection with Enter.

> In fairness I should remark that the URL autocomplete in FF does work more
> like you describe, there is less of a double focus problem: Enter an
> incomplete URL in Firefox (for example just www.): tab and up/down-arrow
> navigate through the menu and supply the value to the URL field. Hover also
> highlights the hovered choice, but enter confirms the "other" choice in the
> URL field, not what is hovered. So if we don't go for a style change as
> suggested in the previous paragraph, you should raise another bug along the
> lines of "Make autocomplete for recipient addresses work more like the FF
> URL autocomplete": Arrows and tab navigate through the menu and supply
> value, enter uses supplied value no matter what is hovered.

Thunderbird should behave the same way as Firefox, definitely wrt the result list's hover and cursor-down behaviour:
- hovering a result item should be inconsequential unless the item is clicked to select it (or you can use cursor up/down to keyboard-select an item starting from the hover position); pressing Enter with contact A suggested and focused in inline autocomplete field and contact B hovered with mouse will confirm contact A because contact B is not yet selected.
- using cursor up/down to navigate the list of autocomplete results will select each entry AND update the main input field accordingly with the currently selected value; pressing ESC closes the dropdown and restores the original user-typed value.

I'm not so sure about TAB-cycling the results list as in FF, but I suppose we could do that, too:

(+) tab-cycling results is a simple swiss-knife way of navigation which rightly coniders the dropdown as the current UI dialogue where easy navigation between elements should occur (TAB key has easy, error-safe location on keyboard and is a big target); to get back into the main tab-cycle, just press ESC to close that dialogue and then use TAB to proceed elsewhere. I'm also sceptical why TAB as a general key for moving focus around should confirm unconfirmed things at the same time; plain Enter for confirmation seems safe, predictable and sufficient to me.
(+) using tab to cycle multiple results could also be good in ux-error-prevention when you wrongly think there's only one match for what you typed; using TAB blindly and prematurely will force you to choose the right one among multiple results.
(-) we'd lose the traditional TAB for confirming autocomplete suggestions AT LEAST IF there are multiple results; however, I'm not sure how many average users would actually be aware of that option at all.  Perhaps we could still keep TAB for confirming single, inline autocomplete result, which seems to feel good because if the single inline result is NOT what you want, you'd normally fix that using DEL or ESC before moving on with TAB, and removing the suggestion when TABbing out might also feel wrong and unexpected.

> The following is irrelevant in the context of the UX discussion, but I'd
> like to mention it:
> 
> A keyboard-only user has absolutely no problem with the current state:
> Option one: They type as much as is required to only have one
> auto-suggestion. Then they confirm with tab or enter.
> Option two: They use the arrow keys to select what they want and then press
> tab or enter.

Keyboard-only users can still become victims of snap-selection errors from unrelated/accidental mouse moves as described but not limited to the user story below.

> (I myself as a mixed user also have no problem: I type part of the address,
> if necessary, click to select (menu goes away!),

Yes, mouse-clicking to select is the correct way. But current Daily already snap-selects on mouse-hover. Which is a problem e.g. when you just want to move the mouse out of the way to see your current keyboard input and it suddenly snap-selects something else.

> tab/enter to confirm. I
> love it, the new autocomplete is great.)

What's the "new" thing about autocomplete that you love?


SAMPLE USER STORY where unintended snap-selection on hover occurs and causes wrong addressing

It's summer in Germany, and I have another user story illustrating the problem of accidental hover errors in Thunderbird autocomplete (whereas FF autocomplete does the right thing): I'm right-hander, so mouse on the right; next to the mouse on the table, a 1,5 liter water bottle to survive the heat. Along the scenario of Bug 1152517 Comment 15, I used mouse to put cursor into recipient field, moved mouse out of the way (mouse pointer happened to end up ca. 1cm below the input), then typed "Ja" to find "Jane". 5 matching entries showed up in results list, say a couple of "Janes", "Johns", "Jennys" or different addresses for the same person etc. Before proceeding to confirm the first match via keyboard, I took a sip from the water bottle and dumped it back onto the table. The resulting vibration of the table was enough to move the mouse by a fraction of a millimeter, and make the hover snap onto a totally unrelated/unintended result from the autocomplete list. Worse (and only in TB), that hovered item was immediately selected (only in TB) AND there was no indication whatsoever that the original inline autocomplete suggestion (still showing in the input box with blue highlight) was now no longer valid. Press Enter or tab while the correct recipient is seen in input box and yet the accidentally hovered result is being filled in and you end up sending mail to the wrong recipient - privacy disaster, ggggrrrr!!!
The point of this bug is simply to decide whether to these two bugs into Thunderbird 38 or not. Comment 16 and comment 17 both seems to agree that we should ship it, so I don't really understand why there is an ongoing UX discussion here. Does anyone want to argue that we should NOT be taking these patches in TB 38?
Thank you Thomas D. 
YES you are completely right!
The bug has to be fixed in all topics (hover, tab, ...) and in the way you describe.

And I encourage the developers to do a two step solution if the complete solution should last any longer now. This bug is such a bad privacy violation that ANY improvement ist worth to be put online asap.

Thanks all you folks for your efforts to make thunderbird adressing work right again!
(In reply to Thomas D. from comment #22)
> > However, I believe that *tab* and *enter* are *confirmatory* actions on a
> > hovered choice, as is a mouse click.
> NO. You can only confirm with keyboard what's already selected. Just
> hovering under normal circumstances must never select something, ...

Please try the userChrome.css (comment #21) so it becomes clear what happens.
  .autocomplete-tree treechildren::-moz-tree-row(hover) {
    background-color: green !important;
  }
  .autocomplete-tree treechildren::-moz-tree-row(selected) {  <===== selected!!
    background-color: #ff8080 !important;
  }

We can argue that hovering shouldn't select, but currently it does.
This bug is done, anything else should be discussed in another bug, as I have already suggested.

> What's the "new" thing about autocomplete that you love?
In TB 24 with the old XPFE widget, which was replaced with M-C's toolkit/autocomplete (bug 959209), the autocompletion was not as powerful, for example
  Hostal Pancheta <info@hostalpancheta.es>
was not found when typing "panch". I don't know why XPFE was replaced by toolkit/autocomplete, this was before my time, I just came on board to fight the consequences in TB 31, like the terrible red addresses (bug 1042561).

Note the following: In SeaMonkey, which AFAIK still uses XPFE, the entry is found with "panch". SeaMonkey seems to behave a lot like you would like TB to behave, I think. Have you tried? One minute to install and export/import the address book. However, going back to XPFE doesn't appear to be an option.

> It's summer in Germany, and ...
It's summer in Spain, and right now, I just can't deal with more text. ;-)
(In reply to Kent James (:rkent) from comment #23)
> The point of this bug is simply to decide whether to these two bugs into
> Thunderbird 38 or not. Comment 16 and comment 17 both seems to agree that we
> should ship it, so I don't really understand why there is an ongoing UX
> discussion here. Does anyone want to argue that we should NOT be taking
> these patches in TB 38?

Sorry about the ongoing discussion. Please take the patches in TB 38 since they fix a really bad aspect.

Dear all: Let's move the discussion elsewhere, that is, to a new bug. As Kent pointed out, this bug is merely here to track landing two M-C patches on the TB 38 release branch.
So it seems we have confirmation it works. I think the issues mentioned are minor after all. Let's land it.
Let's land it.

Further discussion will be done in bug 1192739.
See Also: → 1192739
Blocks: 1192739
You need to log in before you can comment on or make changes to this bug.