1009469 - For recipient autocomplete matches other than {Name beginsWith}, [tab] no longer confirms suggested recipient ("foo >> somefoo <[e-mail]>" is retained as recipient). Suggestion becomes stale/unresponsive when TB loses focus.

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Thomas D. (:thomas8)]

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

For recipient autocomplete, when you get inline suggestion like "foo >> somefoo <[e-mail]>", using TAB with an intention of accepting the suggestion and proceeding to subject field used to work (TB24), but fails now (regression).

STR

1 contact having "somefoo" in any field searched by autocomplete (e.g. First Name)
2 compose msg, type "foo" into recipient input (where "foo" should *not* match anything at the *beginning* of searched fields, this only happens for "contains" matches)
-> so you'll get suggestion "foo >> somefoo <[e-mail]>"
3a Press [Tab] on keyboard
3b another variant: start again from step 2
- don't touch the suggestion
- focus another window, then refocus composition
- press enter on suggestion
3c for comparison: start again from step 2, then press [Enter] on suggestion

Actual Result

3a) Pressing [tab] on suggestion with angle brackets does *not* confirm the suggestion on Trunk (however, we've always used [tab] for confirming as still seen in TB24 release -> regression);
- suggestion with searchword and angle brackets is left behind and very hard to fix after that short of retyping
- focus correctly moves to subject

3b) Another variant: Moving focus away from TB and back without touching the suggestion will make the suggestion become unresponsive: no autocomplete dropdown, [Enter] no longer confirms suggestion (bug)

3c) for comparison, [Enter] on suggestion shows expected behaviour wrt confirming the suggestion

Expected Result

3a) [tab] should confirm suggestion (just like [Enter]), as in TB24 (imo users won't forgive that regression, hence dogfood - why would you press [tab] when you're not yet done with the current recipient?)

3b) Upon temporary loss of focus to another application, while recipient input with suggestion has focus, we should either:
- preserve the UI status exactly, i.e. not change the behaviour of confirming the suggestion in any way, so pressing [enter] or [tab] on suggestion after returning focus to composition window should still work
OR
- confirm the suggestion (?) Confirming the suggestion when recipient input or TB window loses focus would simplify the behaviour a lot and probably fix bug 348844, bug 632127, and bug 749923 in one sweep. However, I'm not entirely sure if we can do that for cases where just *TB* as an application loses focus; it's certainly possible for cases where focus is deliberately moved to somewhere else *inside* TB's composition window as seen in those bugs (similar to the [tab] case).

So I think my recommendation is:
- if user focuses anything else *inside* composition, take that as confirmation of the suggestion
- if TB composition loses focus to another application, preserve the exact focus, state and behaviour of autocompletion as before the loss of focus.

Comment 1

[Thomas D. (:thomas8)]

Sorry, wrong summary from cloning.

Comment 2

[Thomas D. (:thomas8)]

Unless verified otherwise, I assume TB31 is also affected by this, and should be fixed because
- it's very exposed
- really odd to revert when it happens; bad recipient when unnoticed and sent
-> will be highly annoying to users

Comment 3

[Wayne Mery (:wsmwk)]

Attachment: screen shot of autocomplete

Comment 4

[Wayne Mery (:wsmwk)]

Attachment: test address book wsm-test-ab.ldif

Comment 5

[Thomas D. (:thomas8)]

Note that FF bookmark tags autocompletion implemented another use of [tab]:
- typing "f" will inline-autocomplete to tag "f[oo]"
- pressing [tab] will cycle all the other matching tags from autocomplete dropdown

I'm not sure if that's hig/UX-consistent and desirable behaviour; I'd rather expect something like first [tab] to do the autocompletion, second [tab] to move out of the field.

For TB, I'd suggest we remain with the legacy behaviour where first [tab] on suggestion confirms it *and* moves on to subject field. Which looks like simple and intuitive behaviour to me.

Comment 6

[Thomas D. (:thomas8)]

Thanks Mark (:standard8) for immediate attention and feedback.
Perhaps Magnus could fix this?

Comment 7

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #6)
> Thanks Mark (:standard8) for immediate attention and feedback.
> Perhaps Magnus could fix this?

Magnus, you have successfully fixed Bug 1003856 of which this is a remainder (almost same issue).
It's in same category of disturbance and has tracking-thunderbird31+.
Perhaps you could fix this?

Comment 8

[Magnus Melin [:mkmelin]]

Yes, I have a patch that fixes this (just needs finishing up).

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin from comment #8)
> Yes, I have a patch that fixes this (just needs finishing up).

would be good to get this in beta 2, but will need baking first

Comment 10

[Joe Sabash [:JoeS1]]

Attachment: autocomplete results

typing in "arnts" results in what you see in the attachment.
It seems to scroll uo out of sight and apparently is thrown out on send or send later.

Comment 11

[Magnus Melin [:mkmelin]]

My patch in bug 1012398 fixes this, review pending.

Comment 14

[Magnus Melin [:mkmelin]]

Fixed by bug 1012398.

Comment 15

[Nomis101]

This should be fixed now in the latest daily, but I still see this issue. I've tested with 33.0a1 (2014-07-17) Build ID 20140717030251 with and without safe-mode on Mac OS X 10.9.4.
I've used the STR from: https://bugzilla.mozilla.org/show_bug.cgi?id=966053#c20
And sadly I still see this ">>" issue like before.

Comment 16

[Attila Hammer]

With my Ubuntu 14.04 system Thunderbird upgraded with 31.0 version.
When I compose a new e-mail message and typing an address with available the address book, after TAB or SHIFT+TAB key press Thunderbird presenting a new empty to: edit box.
With previous Thunderbird 24.x version after correct autocompleted the typed search match, when TAB key press happening, the caret jumps right the Subject field.
If the autocompletion happened right in Thunderbird 24.x version, when I pressed shift+tab keystroke, the caret jumps back correctly the awailable combo box with possible setting to, CC address type.
Now, in Thunderbird 31.0 I need doing following to the caret lands the subject text box:
1. Type the search term, and the result is autocompleted.
2. Press a TAB key, and press backspace key to hide the empty to: field.
3. Press TAB key again to jump the subject field.
The issue with I expected the 31.0 version not happening if I press ALT+S letter to jump the subject field. If anybody not known this mnemonic letter the subject: widget, need doing I described steps to remove the empty to: text box.

If this is the expected result with I experienced in Thunderbird 31.0, possible toggling off this working method to restore the previous working method? If I filled previous the autocompleted e-mail address and want perhaps adding a new address, simple enough to press an ENTER key.

Attila

Comment 17

[Magnus Melin [:mkmelin]]

There's no need to remove the empty To box, so all you need to do is press tab one more time than before.
Anyway, it's not this bug, so file a new one if you want to discuss it further.

Comment 18

[Peter Lairo]

(In reply to Attila Hammer from comment #16)

+1 for Windows 7. Tab adds extra To:-line; Shift+Tab moves forward instead of back.

If someone does file a new bug on this regression, please post the bug number here. Thanks.

Comment 19

[Attila Hammer]

I filed bug 1043784 this problem related.

Attila

Comment 20

[Thomas D. (:thomas8)]

This bug seems basically fixed (selected and confirmed address is taken over correctly), but the process of cursoring down in the dropdown list of results feels and behaves really wrong, as in screenshot attachment 8421621 [details]:

- it's not right that 2 areas have blue background i.e. active focus at the same time - if I press Enter, will TB confirm the main one or the selection from the list? No way of telling
- when users cursor down dropdown results list, something must visually change in the main recipient line:
  - at least blue background should become light-grey, to indicate de-focusing
  - the original suggestion could be removed?
  - the currently selected result could appear in the main row, probably behind the >> ?

I haven't reflected on correct behaviour much, but the current behaviour feels very odd and non-responsive. Comments?

Comment 21

[Magnus Melin [:mkmelin]]

Yes it's kind of an odd state, because both can get input. I'd like to use tabscrolling for trunk and going forwards, that should fix a bunch of problems. (E.g. like the url bar: when multiple choces tab just moves selection to the next entry down in the list, enter confirms.) Anyway, this bug is closed, so lets not discuss it further here.

Comment 22

[Arthur K. (he/him)]

Although this was seemingly fixed in TB31, it seems mostly resolved in 32b1. Mostly. I can still repro the issue of "foo >> somefoo <[e-mail]>" when I type a name and then click the mouse anywhere in TB. I am doing the same STR: allowing autocomplete to suggest the name(s) and then click the mouse (left or right, doesn't matter). Should I open a new bug for this?

Comment 23

[Magnus Melin [:mkmelin]]

That's bug 1043310.