1192739 - UX confusion when entering recipient addresses ("double focus"): TAB or ENTER unexpectedly uses last-hovered contact instead of typed recipient from input box

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Jorg K (CEST = GMT+2)]

Attachment: Picture to establish the terminology of "filled" and "selected"

This bug is the carry-forward of the discussion started in bug 1187519 comment #17.

To understand the problem, it is easiest to look at the attachment, which was created with the following settings (amongst others) in userChrome.css:
  .autocomplete-tree treechildren::-moz-tree-row(hover) {
    background-color: green !important;
  }
  .autocomplete-tree treechildren::-moz-tree-row(selected) {
    background-color: #ff8080 !important;
  }

As one can see, there is a "filled" value and there is a "selected" value in the popup. There is also a "hovered" value (in green, note the cursor), but that has no significance. (This situation was created by using down-arrow while hovering.)

Thunderbird does this:
- Hovering changes the "selected" value and does not update the "filled" value.
- Arrow keys change the "selected" value, but the "filled" value is *NOT* updated.
- Tab and enter update overwrite the "filled" value with the "selected" value.
  They then confirm the "filled" value (which could have been just the "selected"
  value due to hovering (see point 1).

Firefox does the following:
- Hovering changes the "selected" value and does not update the "filled" value.
- Arrow keys and tab change the "selected" value *and* the "filled" value is updated.
- Enter confirms the "filled" value.

SeaMonkey (using the old XPFE) does the following:
- Hovering changes the "selected" value and does not update the "filled" value.
- Arrow keys change the "selected" value *and* the "filled" value is updated.
- Tab and enter confirm the "filled" value.

I has been argued in bug 1187519 comment #22 that TB should behave like FF. I believe it should behave like SeaMonkey, since tab has traditionally been used to confirm the "filled" value.

Over now to Thomas to add further comments.

Comment 1

[Jorg K (CEST = GMT+2)]

I forgot to mention: TB 24 (before switching over to toolkit/autocomplete in TB 31 in bug 959209) behaved like SeaMonkey still behaves today:
- Hovering changes the "selected" value and does not update the "filled" value.
- Arrow keys change the "selected" value *and* the "filled" value is updated.
- Tab and enter confirm the "filled" value.

I think this behaviour should be reestablished.

Comment 2

[Thomas D. (:thomas8)]

Thanks Jorg for filing this important bug with super-concise description and screenshot, brilliant.

So this bug is the remainder of bug 1152517 / bug 1187519 covering the tab/enter cases first described in my Bug 1152517 Comment 15. As explained there, I'd consider these scenarios to be easy to get into while very nasty in consequence (privacy violation by dataloss of intended recipient -> critical).


(In reply to Jorg K (Thunderbird C-C contributions suspended) from comment #1)
> I forgot to mention: TB 24 (before switching over to toolkit/autocomplete in
> TB 31 in bug 959209) behaved like SeaMonkey still behaves today:
> - Hovering changes the "selected" value and does not update the "filled"
> value.
> - Arrow keys change the "selected" value *and* the "filled" value is updated.
> - Tab and enter confirm the "filled" value.
> 
> I think this behaviour should be reestablished.

+1, I think that's a safe and sound route to take for fixing this bad bug asap.

Jorg, any ideas for resolving the visual double focus problem?
We *do* in fact have double focus (sort of), because typing will occur in the main input, but cursor up/down will start from last selected entry of results list. I'd wish for hover to be less intrusively indicated, as it's NOT selected for most practical purposes; however technically, if we want to keep the snap-select on hover mechanism which is a kind of hybrid, hover effects selection but we can't change the selected style for the real keyboard selections with cursor. I'm not 100% sure about the intentionality or benefits of the snap-select but there might be some. If we'd stop snap-selecting on hover, we could easily disentangle the styles. Not sure how that would affect keyboard-selection via cursor.

We could still reflect and change the TAB behaviour later in analogy to FF if we so wish, along the lines of my Bug 1187519 Comment 22:

> 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.

Comment 3

[Jorg K (CEST = GMT+2)]

(In reply to Jorg K (Thunderbird C-C contributions suspended) from comment #1)
> I think this behaviour should be reestablished.

In hindsight, this is to be taken with a grain of salt. One has to observe very carefully what happens while one types into the field while the autocomplete is busily searching for matches. If tabbing through the results would populate the "filled" value, that would obviously put an end to further typing. Try it in TB24 or SeaMonkey.

As you can see from my current BMO nickname, I've currently suspended contributions that affect C-C. So I won't pursue this issue any further. I just wanted to create a fresh start with a clear bug description.

Just for the record:
Some of the autocomplete stuff is in M-C:
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/autocomplete
https://dxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml
Colours are defined in C-C:
https://dxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/windows/global/autocomplete.css
Pre-populating of the search results happens here:
https://dxr.mozilla.org/comm-central/source//mailnews/addrbook/src/nsAbAutoCompleteSearch.js
There is more processing here:
https://dxr.mozilla.org/comm-central/source/mail/components/compose/content/addressingWidgetOverlay.js
I'm not familiar with any of it, so I don't know where the processing relevant to tab and enter happens.

Comment 4

[Thomas D. (:thomas8)]

(In reply to Jorg K (Thunderbird C-C contributions suspended) from comment #3)
> (In reply to Jorg K (Thunderbird C-C contributions suspended) from comment
> #1)
> > I think this behaviour should be reestablished.
> 
> In hindsight, this is to be taken with a grain of salt. One has to observe
> very carefully what happens while one types into the field while the
> autocomplete is busily searching for matches. If tabbing through the results
> would populate the "filled" value, that would obviously put an end to
> further typing. Try it in TB24 or SeaMonkey.

Well, if you press <tab> you're definitely done with typing either way, and your/our current proposal does not suggest to use tab for cycling through results.
Similarly when you start to cursor through search results, you're certainly expecting to find a match there, i.e. you would not normally continue typing. But, as seen in FF, even after cursoring through results list with updating of the filled value from cursored items, you can still continue typing where you left off after just pressing ESC to exit the results list popup, which will remove any value filled from results list and restore the search as originally typed.

Comment 5

[Jorg K (CEST = GMT+2)]

Damn, I wrote nonsense. This is what I meant to say:

"... If *going through the results with the arrow keys* would populate the "filled" value, that would obviously put an end to further typing."

But you are right, at that stage, the user has most likely finished typing, otherwise ESC is their friend. I wasn't aware of that.

I'd really like to understand why TB is so different from FF given that they both use toolkit/autocomplete. I'd also like to understand why so little attention was paid to the details when replacing XPFE with toolkit/autocomplete. Normally any UX change goes through a lengthy discussion and needs lots of approvals. Yet here one of the most important functions in an e-mail program, capturing the recipients address, was changed introducing grave problems (bug 1043310, bug 1042561, bug 1152517 to name the most obvious ones) and all review and testing failed.

Comment 6

[Wayne Mery (:wsmwk)]

I maybe misunderstanding the UX or severity of this, but when a user can clearly see the UX behavior before their very eyes, and take corrective action, I think attaching the term "dataloss" is a bit expansive. Also, using dataloss to describe "very bad" or unintended behavior weakens the meaning of the term relative to bugs which do have "hard"/physical dataloss in the traditional sense. (Some areas are grey, but the same may apply to predecessor bug 1152517. See also bug 290565, which is essentially undetectible UX behavior, and I think an apropriate use of dataloss term.)

Enable severity, keyword, whiteboard columns of http://mzl.la/1L29f9Q to see a comparision of the use datalossy whiteboard vs dataloss keyword.

Comment 7

[Thomas D. (:thomas8)]

This is essentially the same as bug 1187519, i.e. a very bad and highly exposed bug in one of our key functions, adding recipients in composition. According to comment 1, it's also a regression resulting from the XPFE / toolkit-autocomplete change. I don't see any doubts about the expected UX (Jorg and I already agree! ;), which is just restoring to the TB24 and current SeaMonkey UX. Which also makes us more consistent with FF URL autocomplete behaviour.

So how can we get traction on this bug? Who can fix it?

Comment 8

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #7)
> This is essentially the same as bug 1187519, i.e. a very bad and highly
> exposed bug in one of our key functions, adding recipients in composition.

I really meant bad bug 1152517 with 16 votes and 10 duplicates, whereas bug 1187519 was just landing the latter into TB38x.

Comment 9

[Jorg K (CEST = GMT+2)]

I raised this bug, since bug 1152517 was marked "fixed" without covering all the aspects and therefore the discussion continued in bug 1187519, where is didn't belong.

I agree insofar with Thomas, that the UX is confusing, and it would be more consistent to return the behaviour to what is was, if that's possible, since we don't want to go back to XPFE (I believe, not knowing the reasons for the switch in the first place).

Given Magnus' assessment (bug 1187519 comment #27) (quote)
> I think the issues mentioned are minor after all.
is will be hard to find someone to work on it given the current constraints. Also Magnus told me personally (quote):
> The autocomplete code is surprisingly complex in the details [...] with the controller
> basically supporting two different modes plus a lot of minor options.

I don't know anything about it (see comment #3), I already had a bad time hunting down bug 1042561.

Comment 10

[frogsfarms]

For me it is very simple, I turned all our computers back to version 24.7 which is working properly.
Do not know the reason for your guys to change into the new system, 
but we can not take the chances for mails to end up anywhere I do not want them to go.

Comment 11

[K.J. Petrie]

I don't know the culture/privacy concerns in other parts of the world, but in the UK it would probably be considered a breach of a Data Controller's duty to send an e-mail containing personal data using software which could send it to an unintended recipient. I doubt the Information Commissioner or a judge would consider the issue minor.

I wonder whether the complexity of the code is the problem. Good code should be modular - one task per function if possible. Providing and populating a menu is one (or maybe two functions), highlighting a provisionally selected item is another, and confirming the selection is a third. Moving on to the next field is a fourth. There should be four or five separate functions, each handling one part of the process. Is that the way it's written? If not, it might be simpler to rewrite the lot than to try anticipating special-case scenarios.

Of course, deciding how it ought to work is a prior step. I would think looking for the consensus in Windows/Mac/*nix desktops might inform most of that. Users have expectations which should only be broken for really good reasons.

Comment 12

[K.J. Petrie]

Oh, and mouse, keyboard and touchscreen users have different expectations. Hovering with a mouse should require a click to confirm. Highlighting with an arrow key should need Enter. Touching with a finger or stylus should both select and confirm.

Comment 13

[Magnus Melin [:mkmelin]]

(don't have anything to add)

Comment 14

[Nils Bruechert]

This bug is approaching its anniversary. This is a serious bug, I have resorted to writing all adresses manually after some mail ending up with a wrong recipient. I would be really really grateful if someone could fix this :-)

Comment 15

[Jorg K (CEST = GMT+2)]

(In reply to Nils Bruechert from comment #14)
> This bug is approaching its anniversary. This is a serious bug, I have
> resorted to writing all adresses manually after some mail ending up with a
> wrong recipient. I would be really really grateful if someone could fix this

Fixed by bug 1303304 in TB 51. Bug 1303304 will be uplifted to TB 50, so try TB 50 beta coming out in a few weeks.