1164747 - Recipient autocomplete is slow (input buffer delay!), toplists unexpected address, sometimes uses wrong address

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[ted thomas]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150511103819

Steps to reproduce:

When I create a new e-mail, I rely upon the automatic search function to narrow the field of possibly matching recipient names to those which "start with" the characters I've typed. This function no longer works properly, and it started malfunctioning fairly recently (probably within the last six months).


Actual results:

First, I am now getting a noticeable and lengthy input buffer delay when I type in the first few characters of the recipient address. By that I mean, Tbird stops echoing characters at an arbitrary point, so I don't know for sure how many I've typed that haven't been echoed to the screen. 

Second, if I select an address from the drop-down list by moving the selector bar over the address and hitting enter, I sometimes get the address I thought I wanted, and other times (frequently after the e-mail has been sent to the wrong person), I discover that the "Selection Wizard (idiot)", didn't put the one I wanted into the "To:" slot. 

This can have disastrous consequences if it results in sending an e-mail to the wrong person selected from your address book.


Expected results:

It appears someone has decided the matching code for finding a recipient address wasn't "ingenious" enough, and tried to make it a whole lot "smarter". 

Perhaps a solution to this problem would be to allow the user to select which matching protocol should be used. It seems to me the logical default case would be a case-insensitive search on the actual recipient e-mail address (which ignores whatever name is associated with that address). If someone wants a more complicated search protocol, make that a selectable item in the chrome registry.

When it comes to indicating which address you want to use, it's useful to remember that the user is likely using the keyboard and not the mouse while typing in the leading characters of the recipient address. Therefore, the code should be prepared to select whatever e-mail address is directly under the cursor if the user hits enter, rather than removing one hand from the keyboard and selecting the address with the mouse.

Comment 1

[Thomas D. (:thomas8)]

(In reply to ted thomas from comment #0)

Hi Ted, sorry for the inconvenience! We've fixed many issues for the upcoming Version TB 38.
(Otheriwse this bug covers too many problems in one report, so it's technically invalid.)

> Steps to reproduce:
> 
> When I create a new e-mail, I rely upon the automatic search function to
> narrow the field of possibly matching recipient names to those which "start
> with" the characters I've typed.

We call it "Recipient autocomplete"

> This function no longer works properly, and
> it started malfunctioning fairly recently (probably within the last six
> months).
> 
> 
> Actual results:
> 
> First, I am now getting a noticeable and lengthy input buffer delay when I
> type in the first few characters of the recipient address. By that I mean,
> Tbird stops echoing characters at an arbitrary point, so I don't know for
> sure how many I've typed that haven't been echoed to the screen. 

Please file that as a new bug with detailed and numbered steps how to reproduce, conditions (how many contacts in your ABs).

> Second, if I select an address from the drop-down list by moving the
> selector bar over the address and hitting enter, I sometimes get the address
> I thought I wanted, and other times (frequently after the e-mail has been
> sent to the wrong person), I discover that the "Selection Wizard (idiot)",
> didn't put the one I wanted into the "To:" slot. 

Probably Bug 1152517 - make sure your mouse is not over the results list until we've fixed that.

> This can have disastrous consequences if it results in sending an e-mail to
> the wrong person selected from your address book.

Indeed. :(

> Expected results:
> 
> It appears someone has decided the matching code for finding a recipient
> address wasn't "ingenious" enough, and tried to make it a whole lot
> "smarter". 

No need for irony...
The autocomplete toolkit code had changed and we had to adapt to that.
And we changed the algorithm, too, to fix known failures which many users complained about, e.g. that typing "doe" would not find "[e-mail]". So yes, it's smarter and correcter than before.
When trying to fix the downsides, we took it too far by giving initial display names absolute priority.  This will be mostly fixed for TB38.

> Perhaps a solution to this problem would be to allow the user to select
> which matching protocol should be used.

Yes, that's the ultimate goal. We're not there yet. Bug 118624 has a tentative approach to that.

> It seems to me the logical default
> case would be a case-insensitive search on the actual recipient e-mail
> address (which ignores whatever name is associated with that address).

No, that's NOT the logical default at all. Different people, different needs.
But I think we've fixed what bothers you in Bug 1134986, so in TB 38 searching for email addresses should work as you expect (while we also allow searching for names).

> If someone wants a more complicated search protocol, make that a selectable
> item in the chrome registry.

It's the efficiency for finding things which matters, not the complexity of the algorithm.
It's not perfect yet and never will be, but TB 38 should largely cater for everyone as wrt result sorting it's almost like before only with a few more extra results further down the list which were missing before.
FF location bar has a very complex algorithm which users seem to be very happy with because it succeeds most of the time to get it right, and it adjusts dynamically as users preferences change over time.
We'll try that, too, in Bug 382415.

> When it comes to indicating which address you want to use, it's useful to
> remember that the user is likely using the keyboard and not the mouse while
> typing in the leading characters of the recipient address. Therefore, the
> code should be prepared to select whatever e-mail address is directly under
> the cursor if the user hits enter, rather than removing one hand from the
> keyboard and selecting the address with the mouse.

That sounds very much like Bug 1152517. If not, please file a new bug with detailed STR in numbered, concise steps.

Comment 2

[Thomas D. (:thomas8)]

For other bugs we're in the process of fixing and which can cause the wrong address to be selected, please read Bug 1130858 Comment 6.

Comment 3

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #1)
> (In reply to ted thomas from comment #0)
> > Actual results:
> > 
> > First, I am now getting a noticeable and lengthy input buffer delay when I
> > type in the first few characters of the recipient address. By that I mean,
> > Tbird stops echoing characters at an arbitrary point, so I don't know for
> > sure how many I've typed that haven't been echoed to the screen. 
> 
> Please file that as a new bug with detailed and numbered steps how to
> reproduce, conditions (how many contacts in your ABs).

Actually, we already have a bug for the initial slow reaction of autocomplete:
Bug 1085674