1151520 - Thunderbird address auto complete gives no results after quick return key. Address auto complete is too slow

Status: RESOLVED WORKSFORME

(Toolkit :: Autocomplete, defect, P3)

Description

[Martin]

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150402191859

Steps to reproduce:

Version 31.6.0 (as installed by build in auto updater)

Quite a while back now there was a huge drop of the speed for the autocomplete feature when entering an address in "TO" field of the compose window. 
According to google searches, this is because the autocomplete now also searches inside the text of each field..

In any case, it was possible (without any need of waiting) to enter 2 or 3 letters, and hit return immediately, and an address was completed.


Actual results:

Typing a few letters enough to either identity only one, or have the desired entry listed first, and press return (without waiting)

=> no auto completion happens, because the search has not yet returned results. 

Also (if I wait) results matching are in a different order now, meaning all my 2 or 3 letter starts no longer work)


Expected results:

Restore (as an option) the old search behaviour, with the more limited list, and the old ordering.

Or if there where other changes in behaviour restore them. 
That is maybe earlier versions did not process the return key, until auto repeat returned a list? So they always auto completed, while now the key does not trigger auto complete.

Comment 1

[Thomas D. (:thomas8)]

We are aware of these problems and still in the process of addressing them.
Some of them have already been addressed for upcoming TB38, where your 2 or 3 letter shortcuts should work again unless you're searching in the middle of fields ;)

Comment 2

[fantasai]

I am still seeing this on 38.2.0.

Comment 3

[Thomas D. (:thomas8)]

Hmmm. I think it's premature to confirm this, and it won't help because we can't act on this: comment 0 mixes too many issues, performance, real bugs etc. And per my comment 1, there's still ongoing work in other bugs.

Pls see "see also" field of this bug if the problems listed there are yours.

Comment 4

[Wayne Mery (:wsmwk)]

THis is still a problem after bug 1012397 was fixed. I don't think this is related to bug 1085674.

Comment 5

[Wayne Mery (:wsmwk)]

Martin, fantasai,
When using a nightly build, does return/enter key still fail as described in comment 0? (it does for me)
nightly: https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/

Comment 6

[Wayne Mery (:wsmwk)]

This lacks sufficient recent feedback from the original reporters However, comment 0 states "hit return immediately, and an address was completed", so I'm going to repurpose this bug to that one use case.

My address book has ~1700 contacts, and an ldap addresbook. This happens with or without ldap enabled.

Steps:
1. Have a contact that will autocomplete after typing in "test". Two tests:
2. Type test, then quickly (in less than 1 sec) hit enter key.
Address is not filled in.

Compare to tab key: Type test, then quickly hit tab key. Address is immediately filled in. (

bug 1012397 fixed or improved this for the tab key. But not enough for the return key.

Comment 7

[Paul Ausbeck]

To me, it seems odd that the enter and tab keys could have different autocomplete behaviors. But also to me, the entire autocomplete implementation seems odd as relates to email addresses. After posting a duplicate bug, 1239818, on this issue and reading the feedback on that and another related bug, 1012397, I was motivated to try and understand the historical progression. First, I tried to parallel install Thunderbird 24.x, but had too much trouble with it undesirably using my 31.x profile. So then I thought I'd try MS Outlook, which is what I used before moving to Thunderbird some years ago. It turns out that Outlook is where my expectations appear to originate. In Outlook, nicknames, display names, and full email addresses are interchangeable on the same address line. So one can just natually type a sequence of nicknames separated by semicolons in a single recipient list. The translation from nickname or display name to actual email address is done somewhere in the background. After some further rumination, I also seem to remember that this automagical translation of nicknames to addresses also was a feature of the original "mail" command line client. I mean, what is the purpose of a nickname if you can't type a sequence of them separated by semicolons into a recipient list? Doing some sort of fancy lookup spanning every bit of data on the hard drive just doesn't seem appropriate for email addresses. Keep it simple, limit it to nicknames and perhaps display names, and make it easier to just cut and paste from the address book for infrequently used addresses.

It seems that recent changes are directed toward easing Thunderbird's use on phones or tablets. That in of itself, isn't a ridiculous idea, but it shouldn't ruin the experience on a conventional machine. One UI can't be made optimal for all machine form factors as should be pretty obvious from Microsoft's one Windows everywhere campaign. Let's not have one Thunderbird everywhere.

Comment 8

[Jorg K (CEST = GMT+2)]

In bug 1192739 there is some discussion on the use of <tab> and <enter>.

Comment 9

[Paul Ausbeck]

After looking at bug 1192739 I'm convinced there is a bit of a disconnect between the complainers, including me, and the implementors. I'd like to offer another example that I hope is particularly illustrative. Let's say that I want to send a message to my Mom, Dad and sisters. I click on the Thunderbird "Write" button and start typing: Mom, Dad, Barbara, Sarah <Tab>. What I get is the string "Mom, Dad, Barbara, Sarah" in the To: field and the cursor in a second magically appearing To: field, when what I want is for the cursor to advance to the the Subject: field and for the four Nicknames/Aliases that I entered to be expanded so that Thunderbird won't complain that "Mom, Dad, Barbara, Sarah" is not a valid email address when I later attempt to actually send the message. It would be preferrable, at least to me, if the aliased addresses were expanded on a single To: line, but I could live with three magically appearing To: lines in addition to the first and the four completed addresses distributed into the four To: lines. I want to emphasize, that this is NOT a timing/performance issue, in that I can wait as long as I like between typing each character in the above described To: line and I still get the same undesirable behavior.

Basically what I'm looking for is what I could do back in 1985 just using the original "mail" user agent and alias commands in my ~/.mailrc file.

Comment 10

[Martin]

Ignoring the need for multiple addresses in one line, that would probably be an option.

And maybe that is what actually happened in older thunderbird (dont know).

Maybe older thunderbird did not process messages while it was searching. So even if I pressed tab, it would continue to search, and tab was only processed when search results were available, therefore the first found email from my addressbook would be used.

Now tab is processed during the search, so thunderbird keeps the meaningless content in the to field.

So what needs to happen, is that when tab is pressed (and the to-field is not a full email), the search needs to continue, and the to-field should get the search result, once it is available.

In that case the search speed does no longer matter, as search will always continue and finish.

Of course that means, if I enter a 2nd to-address in a 2nd to-field, while the search in field 1 is still running, then 2 (or more) searches will run in parallel.

Comment 11

[Magnus Melin [:mkmelin]]

Tht(In reply to Martin from comment #10)
> So what needs to happen, is that when tab is pressed (and the to-field is
> not a full email), the search needs to continue, and the to-field should get
> the search result, once it is available.

That's how it works (since bug 1012397).

Arguing that you should be able to input multiple nicks comma separated and then filled in later is a bit odd, since autocomplete will come up and suggest things way before you have time to enter all the nicks. So in practice you can't easily get into that situation.

Comment 12

[Joey Connick]

(In reply to Magnus Melin from comment #11)
> Tht(In reply to Martin from comment #10)
> > So what needs to happen, is that when tab is pressed (and the to-field is
> > not a full email), the search needs to continue, and the to-field should get
> > the search result, once it is available.
> 
> That's how it works (since bug 1012397).
> 
> Arguing that you should be able to input multiple nicks comma separated and
> then filled in later is a bit odd, since autocomplete will come up and
> suggest things way before you have time to enter all the nicks. So in
> practice you can't easily get into that situation.

I agree... that's a feature request, not related to this (very specific) bug.  Feel free to file it as such.

Comment 13

[Martin]

(In reply to Magnus Melin from comment #11)
> Tht(In reply to Martin from comment #10)
> > So what needs to happen, is that when tab is pressed (and the to-field is
> > not a full email), the search needs to continue, and the to-field should get
> > the search result, once it is available.
> 
> That's how it works (since bug 1012397).
> 
> Arguing that you should be able to input multiple nicks comma separated

I dont ask for the multiple nicks.

As for bug 1012397, seems that fix is in 38.7.0? At least I just tested, and that actually works.

The only problem is, that it only works with the tab key:
- m,a,tab => martin@...
- m,a,return => ma  no completion happens.

So depending on if that is the last recipient that I enter, or I want to enter more of them, it works or not.

If the same fix could be applied for return key, then to me this would be fixed.

Comment 14

[Paul Ausbeck]

Speaking solely for myself, who learned to type on an actual typewriter, not looking at the typewriter or screen but usually some piece of paper, it's somewhat annoying to be told that I can't easily get into a situation that I easily get into all the time. Also speaking solely for myself, it seems odd that a feature that was in unix mail circa 1985, that I personally remember was in the original Netscape email client circa 1995, and by extension was likely in original versions of Thunderbird, was in Outlook Express, and is in Microsoft Outlook, is no longer working in recent Thunderbird versions.

It seems that a lot of people really like this new scheme of automagically creating a new To: line for each recipient, but I personally find it very inefficient and annoying. A bug actually.

I've said this a number of times but I'll say it again, autocomplete is/should mostly be interesting to novices and touchscreen users. It should not interfere with touch typists. Right now it is grossly interfering with touch typists.

Comment 15

[Jorg K (CEST = GMT+2)]

(In reply to Paul Ausbeck from comment #14)
> It seems that a lot of people really like this new scheme of automagically
> creating a new To: line for each recipient, but I personally find it very
> inefficient and annoying. A bug actually.
There is bug 440377.

Comment 16

[fantasai]

This bug is about an autocompletion timing issue, specifically that autocomplete fails if you are a fast enough typist. If you have other complaints, file a separate bug.

To answer wsmwk's question, yes this still fails for me. In fact, there are three different results I can get, depending on timing:

  add<tab> -> add
  add<tab> -> add >> Address Book <[e-mail]>
  add<tab> -> Address Book <[e-mail]>

The middle one is in particular quite a weird result. Tested on Thunderbird 38.6.0.

Comment 17

[Paul Ausbeck]

OK, I've done some study and agree that this bug is about autocompletion timing. The timing issue was introduced in Thunderbird 31x and other than the timing problem no other obvious changes, at least to me, were made to the message address fields from version 24x.

But, I was still interested in the Thunderbird history of address lists. It turns out that Thunderbird version 2.0.0.24 was the last version to reasonably support comma separated addresses. So the current behavior can be considered to be a regression, but given the time to notice, only sort of. Anyway, the 2.0 behavior is that a comma separated list of addresses typed into a To: field is automagically distributed to the proper number of separate To: fields, each autocompleted upon entry termination in the first field via <Tab> or <Enter>. Starting in version 3.x, the automagical distribution remains, but autocompletion of each separate field does not occur. The recent behavior is that a comma separated list of addresses is neither distributed to separate fields or autocompleted upon <TAB> or <ENTER>, but a comma in the To: field causes a new blank To: field to be created. I'm not exactly sure when the version 3x behavior was lost, but sometime after version 10x.

After looking at the history, I was wondering why it took so long, at least a couple of years, for me to notice that a comma separated list of addresses is not supported in Thunderbird. I'm thinking now, that I did notice, but just stopped using comma separated address lists when I started using Thunderbird. That got me thinking about the history of my emailing from home. I started using Thunderbird sometime between 2-5 years ago when I switched from Microsoft IE to Firefox, switching at the same time from Outlook to Thunderbird. Before that I had been using IE and Outlook 2000 since, yes, 2000. Before that IE and Outlook Express since about 1998 when I switched from Netscape Communicator in the version 4 debacle. Before that, yes, Netscape Communicator since about 1995 and before that unix mail on a Netcom shell account since about 1991.

Anyway, the upshot is that up until Thunderbird, every other email client that I've ever used supported comma or semicolon separated address lists. It turns out that Thunderbird originally supported this as well and lost that ability in the transition from version 2 to 3. Noticeable vestiges of support remained until around version 17 but currently only barely noticeable vestiges remain.

All interesting.

Comment 18

[fantasai]

Interesting, but not relevant. Please keep bug reports focused on the bug they're reporting. Thanks~

Comment 19

[Paul Ausbeck]

Well I disagree that my comments are irrelevant. In particular, if Thunderbird had not lost the ability to correctly process recipient lists, this current bug report would not be present.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to Paul Ausbeck from comment #7)
> ...
> 
> It seems that recent changes are directed toward easing Thunderbird's use on
> phones or tablets. That in of itself, isn't a ridiculous idea, but it
> shouldn't ruin the experience on a conventional machine. One UI can't be
> made optimal for all machine form factors as should be pretty obvious from
> Microsoft's one Windows everywhere campaign. Let's not have one Thunderbird
> everywhere.

THis is just speculation and there is no truth in it. And this bug has nothing to do with multiple addresses on a single line, comma separated or otherwise. Please take these comments somewhere else.

Comment 21

[Paul Ausbeck]

Hmmm, insults followed by false politeness. I must have touched a nerve here somewhere.

Comment 22

[Martin]

(In reply to Paul Ausbeck from comment #19)
> Well I disagree that my comments are irrelevant. In particular, if
> Thunderbird had not lost the ability to correctly process recipient lists,
> this current bug report would not be present.

Just to clear this up. I am the reporter of this issue. I do not use the comma separated syntax, so this bug does exist independent of the comma issue.

This bug is that when you:
- type in a (small) part of a single email (or name from address book)
- then press tab or return
and do all this very fast, then completion does not happen.

Any other completion related issues are not part of what I reported. 
My understanding (but that may be wrong) is, that as soon as the issue that I reported is solved, the report will be closed, and comments about other (even related) issues may be lost. So please follow the advice by others and open a separate report for it. From my personal experience that is more likely to get your issue fixed. (just my 2 cents, and sorry for this paragraph itself being offtopic to the report.)

-------

As for my report, see my comment from 2016-03-16 15:14:29 PDT, in thunderbird 38.7.0 this is partly fixed by the solution of bug 1012397. At least I consider the new behaviour (deferred completion) a fix to my report.

However this fix only affects completion by the tab key. The return key does not trigger the deferred completion. So the fix still needs to be expanded to include the return key.

Comment 23

[Paul Ausbeck]

Martin, thank you for the carefully crafted response. FYI, I'm not directly expecting to get comma delimited lists working again via this bug report, especially now that I've discovered that it hasn't been working since version 2.x. But I do think that my comments should be interesting and useful to the maintainers. Perhaps at some future point, someone will gain enough confidence in the code to tackle the comma delimited issue without an actual bug report. It's definitely a regression and should be fixed as it's a useful feature. Also, it seems likely that basic timely completion will not be really fixed until a proper completion infrastructure has been restored.

I agree that the delayed/failed completion issue is more important than comma delimited completion. After all, I was able to work around the comma delimiter failure by just not using delimiters. But this failed/slow completion is devilishly difficult to work around. Even after 100's of failures, I still occasionally forget to look at the screen for a successful completion before pressing the Tab key, and only find out after I've composed the message and attempt to send. However, I still puzzled as to how comma delimited completion got lost in the first place. Certainly, many people must have been using it, so it seems that I'm not alone in just silently adapting.

Comment 24

[Paul Ausbeck]

After sleeping on this I searched for and found bug 392932, the oldest report of problems with comma delimited lists that I could easily find, and linked it to this one via comment. I've included the last paragraph of my comment there, here:

"One last item of note is that it seems from the age of this regression that Thunderbird is not being as actively maintained as I had thought. My mental model was that as an official Mozilla project, Thunderbird would have at least several semi-professional/expert-amateur maintainers. My feeling now is that that is not the case and perhaps Thunderbird maintenance is now largely up to the coding-skilled portion of the user base. Sort of the "if I want this fixed, I'll do it myself mentality". So is that the case, does Thunderbird welcome user generated patches?"

Wow, I just noticed that my previous comment was "hidden" as off-topic. Likely that this one will suffer the same fate. Things just get curioser and curioser...

Comment 25

[Magnus Melin [:mkmelin]]

(In reply to Paul Ausbeck from comment #24)
>. So is that the case, does
> Thunderbird welcome user generated patches?"

Yes of course!
Thunderbird is actively maintained by the community, with Mozilla providing the infrastructure.

Comment 26

[Paul Ausbeck]

Well I have some inclination to contribute to Thunderbird as I do use it. Also, I may have more time to devote to quixotic tasks than average. But I'm not convinced just how welcome any efforts may actually be, exclamation points aside. Given that if I were to look at this problem, it would be in the context of bug 392932, I was wondering if whomever hid my previous comments as off-topic may reconsider his/her action. Just in isolation, it seems absurd to hide comments but then leave responses to them unhidden.

Comment 27

[fantasai]

The response included additional information relevant to this bug, that's why it wasn't hidden.
Now please stop speculating on this bug. If you have comments about comma-separation, post them in *that* bug. One bug per report, please. Crossing topics clutters the report and makes it harder for everyone else to figure out what's going on.

Comment 28

[Paul Ausbeck]

Disagreement with a single person is one thing, disagreement with an entire community, quite another. I find the trickiest part of life is deciding on when to flush past effort as wasted. The metric I use is whether or not something can be learned from further effort. For instance with this post I can turn passive agreement into active. Isn't there just one person out there with an inclination towards my point of view? You must be quick or determined, a tree fallen in silence is hushed forever.

Comment 29

[Wayne Mery (:wsmwk)]

(In reply to Martin from comment #22)
> (In reply to Paul Ausbeck from comment #19)
> > Well I disagree that my comments are irrelevant. In particular, if
> > Thunderbird had not lost the ability to correctly process recipient lists,
> > this current bug report would not be present.
> 
> Just to clear this up. I am the reporter of this issue. I do not use the
> comma separated syntax, so this bug does exist independent of the comma
> issue.
> 
> This bug is that when you:
> - type in a (small) part of a single email (or name from address book)
> - then press tab or return
> and do all this very fast, then completion does not happen.
> 
> Any other completion related issues are not part of what I reported. 
> My understanding (but that may be wrong) is, that as soon as the issue that
> I reported is solved, the report will be closed, and comments about other
> (even related) issues may be lost. So please follow the advice by others and
> open a separate report for it. From my personal experience that is more
> likely to get your issue fixed. (just my 2 cents, and sorry for this
> paragraph itself being offtopic to the report.)
> 
> -------
> 
> As for my report, see my comment from 2016-03-16 15:14:29 PDT, in
> thunderbird 38.7.0 this is partly fixed by the solution of bug 1012397. At
> least I consider the new behaviour (deferred completion) a fix to my report.

Unless I read the bug reports that's not possible, unless you hand applied the patch or tested v44 or newer, because the patch was not uplifted to version 38.

Comment 30

[Robert]

Hello,

I hit the same bug as described in Comment 22.
I've just tried version 45 and the bug is still here.

I believe it's not a matter of completion being fast or not, 
it's just about completion going on in background when the focus has moved to another field. 
In this case, the first match was chosen, lucky you if it's the good one (and this way was perfect for me !)

Robert

Comment 31

[Jorg K (CEST = GMT+2)]

I can confirm that this is still a problem on current trunk (TB 50).

Have an address in your address book that would normally autocomplete. For example, when I type "he" and wait before hitting enter, I get [e-mail].

If I type "he" and hit enter very quickly, I get "he" as recipient and it's not even red.

Variation:
Enter "he" and let is autocomplete to [e-mail]. Then select this and type he<enter> quickly. Same as above, recipient "he" and it's black. Alternatively, overwrite with xz<enter>. That comes out in black, although "xz" when waiting comes out in red.

Magnus, autocomplete is your field: Are there any plans to address this bug? You only commented in comment #11 that after bug 1012397 all is well when you use <tab>. I can confirm that, but it's not well when using enter.

Comment 32

[Jorg K (CEST = GMT+2)]

(CC: Aceman: I'm revisiting these autocomplete bugs since I reviewed your bug 1290729 and had to play around with adding recipients.)

Comment 33

[Jorg K (CEST = GMT+2)]

Further to my comment #31:
In bug 1012397 comment #114 and bug 1012397 comment #117 (and more), they complain that only <tab> was fixed but not <enter>. So what are the plans for fixing <enter> as well?

Comment 34

[Magnus Melin [:mkmelin]]

Might be this, from looking at it a bit: for enter we should hit awReturnHit -> awAppendNewRow -> awSetFocus, which sets focus to the new element in a timeout
https://dxr.mozilla.org/comm-central/rev/01f5f751c3aad6ef989081f49e9a0c377886796b/mail/components/compose/content/addressingWidgetOverlay.js#719

For tab, we set focus instantly to the subject element.

Maybe the timeout causes this.focused in onSearchComplete to be still true so things fail.

Comment 35

[Jorg K (CEST = GMT+2)]

Would you like to take this bug, Magnus?

Comment 36

[Magnus Melin [:mkmelin]]

Feel free to take it if you like, I'm not sure when I'll have time to test that theory and come up with a solution.

Comment 37

[Jorg K (CEST = GMT+2)]

Attachment: WIP: Debug patch

Personally I think is was mistake to "fix" bug 1012397. There can't be autocompletion if the autocompletion hasn't even had the chance to display anything. Bug 1012397 implemented ignoreblurwhilesearching in toolkit/autocomplete so that the autocomplete doesn't stop when the input field loses focus when the <tab> key is pressed.

If you use the new timeout preferences from bug 1085674, you can see that <tab> moves the focus to the subject field and the autocompletion of the addressing field comes seconds later out of the blue (if the initial delay was set to - say - 5000). I think this is a horrible hack. The user can type quickly and confirm with <tab> even though no autocomplete result was displayed at all. Just out of experience they know that the first entry is the right one. That will of course fail horribly it a new entry gets added to the collected addresses which may sneak in first instead.

IHMO bug 1085674 was a WONTFIX, and we can still undo the damage by removing ignoreblurwhilesearching="true" from messengercompose.xul to make it work safely, reasonably and the same as the <enter> key.

Without having looked at it much further, <enter> will terminate the autocompletion, even unsuccessfully, so there is no way we can play the same evil trick we've done for bug 1012397.

That said, I tried Magnus' suggestion as per the attached patch with no success. Correct me if I'm wrong, but once you hit <enter>, the game is over and there won't be any autocompletion.

Opinions? Magnus, Aceman?

Comment 38

[Jorg K (CEST = GMT+2)]

I forgot to paste the fix from bug 1012397 here:
https://hg.mozilla.org/mozilla-central/rev/ac6ad9e34835

Comment 39

[Magnus Melin [:mkmelin]]

(In reply to Jorg K (GMT+2) from comment #37)
> success. Correct me if I'm wrong, but once you hit <enter>, the game is over
> and there won't be any autocompletion.

Well that's this bug isn't it?

Many people complained about bug 1012397 before it was fixed. I think chances it ends up well are good enough for people, compared to the annoying alternative that you *anyway* have to fix up what you wrote. We top list popular addresses, so a new address sneaking in on top isn't all that likely.

Comment 40

[Jorg K (CEST = GMT+2)]

(In reply to Magnus Melin from comment #39)
> (In reply to Jorg K (GMT+2) from comment #37)
> > Correct me if I'm wrong, but once you hit <enter>, the game is over
> > and there won't be any autocompletion.
> Well that's this bug isn't it?
That's in the eye of the beholder. I find it funny that autocomplete should deliver a result although it never ran. I think you will have a really very hard time to convince M-C that you should allow a way to type <enter> before the autocomplete delivered any result just like was hacked together for <tab>. Anyway, let's ask Marco.

> Many people complained about bug 1012397 before it was fixed.
I know, there are many duplicates.

> I think chances it ends up well are good enough for people, compared
> to the annoying alternative that you *anyway* have to fix up what you wrote.
There is no annoying alternative. You just wait the 300 ms of timeout it takes to autocomplete (or reduce the timeout further via the new preferences in bug 1085674) and then confirm what you see instead of blindly replying on the system to get you the right result.

Marco, triggered by bug 1302472 some sleeping dogs have woken up. Here's our question.

Apparently there is a 300 ms delay on autocomplete, so if the user hits <tab> or <enter> in the first 299 ms before the popup shows, they get no autocomplete. This was changed/fixed for <tab> in bug 1012397 where Neil added ignoreblurwhilesearching="true" for toolkit/autocomplete which we use here:
https://dxr.mozilla.org/comm-central/rev/26f04790ea9c46a3bc5a18ec18826b8bd790ffbe/mail/components/compose/content/messengercompose.xul#955

In bug 1085674 we're introducing configurable timeouts, so if I set the timeout to 5000 ms instead, type something into the widget and hit <tab>, the logic in TB focusses on the subject immediately. Five seconds later the field where I typed is autocompleted. With "normal" Thunderbird you can't see that, but increasing the delay to five seconds, this strange effect is visible: Autocompletion of a field that has long lost focus.

So as far as users are concerned, the <tab> case is fixed. If I do the same, but hit <enter> instead of <tab>, the next addressing field is focused, but the previous one doesn't get autocompleted.

Now, I believe that <enter> processing is deeply embedded in autocomplete and it would be hard to implement the same (questionable) effect for <enter>.

Please let me know what you think.

Comment 41

[Martin]

If there is such a controversy then at least make it an option.

I can see why there is an argument against it. A person not expecting this behaviour might get an unexpected result. Well only if they tab (or enter) away before finishing the name. (And why would you tab/enter unless you expect this)

On the other hand, in favour for the auto completion: Before the "tab" part was fixed, almost every emay I wrote simple had only 1 or 2 chars in the "to" field. And then I had to go back to the field and do it all over again. Huge loss of time (accumulated).

------------------
There is another solution. (not my favourite, but ...)
If the completion drop down did not occur, search for an exact match in any one (exactly one) field of the address entries (incl: nick). [Or even better, instead of matching any field, create a new field: "auto complete alias" in each address book entry / must be unique across all entries]

So if I enter Martin, tab (or Martin enter) then it will complete, but only if there is just one contact that has an exact match.
And if I give myself the nick "M", then I can just type M-tab.

This means, more work to set it all up, but then it is save. If I enter a none-email, it will be replaced as expected.
And it solves the problem I reported when I created the issue: Enter one or a few chars and *always* get an expanded email (without any need to wait).

And this also can be used for off topic comment 17.

Comment 42

[Joey Connick]

Hi,

I have to admit I don't understand all the vagaries here... but what I do know is, as a user, either hitting tab or enter to autocomplete *used to* work the same (emphasis on "it worked"), and now it doesn't.  It shouldn't matter what the timeout value is--they should work the same, as previously.  If they don't, then anyone sending to multiple recipients who relies on autocomplete is hosed, because hitting tab switches the focus from the address list to the Subject field, so enter has to be used for multiple recipients and if autocomplete doesn't happen (like it used to), that means broken recipients when adding multiple recipients.

The above "another solution" in comment 41 is not a solution.  That's a kludge that will require a lot of people rejiggering their address books to be able to make things work that used to "just work."

This is a bug that needs fixing, not a workaround.  If the new search method is so slow that it creates all these problems, well then perhaps that approach to address search should be rethought or at least properly optimized.

But at the very least, hitting either tab or enter should have the same behaviour as it used to (i.e. triggering autocomplete).  Tab has been fixed; please also fix enter.

Comment 43

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Jorg K (GMT+2) from comment #40)
> That's in the eye of the beholder. I find it funny that autocomplete should
> deliver a result although it never ran. I think you will have a really very
> hard time to convince M-C that you should allow a way to type <enter> before
> the autocomplete delivered any result just like was hacked together for
> <tab>. Anyway, let's ask Marco.

FWIW, this can already be done in the frontend binding code.
It's what we do for the awesomebar (only for Enter though, one day we may want to do the same for Tab and Down), http://searchfox.org/mozilla-central/search?q=handleEnterInstance
You can intercept events (Enter, Tab) and delay them to when you get the first result. Though, that assumes knowing if there's a first result and returning it fast enough.
Indeed UnifiedComplete.js returns a Result with a first match as soon as it has one, and sets RESULT_SUCCESS_ONGOING to wait for further matches (added to the same result object).
We also removed the delay for the search returning the first result (autofill), and instead we delay the next searches that are more expensive in the search component, rather than in the widget.
It would probably be good to handle it at the toolkit level, but it's also scary, if one attaches a search that takes long to deliver any result, to the user it would look like the UI is stuck or broken. So there should be some sort of opt-in attribute in the input field.
It may be more complex for thunderbird if it allows other kind of completions that is not to the first match.

I think in the end it boils down to the search component and how fast it can provide results, plus how well you can predict a result coming from the frontend code (cause you don't want to wait forever a result that will never come).

Whether the handling could be managed at toolkit level, probably yes, if there would be someone available to work on it, with a clear plan of the wanted outcome and willing to create something that would also cover ulrbarbindings needs. And it should be opt-in.

Comment 44

[kidservice]

Just to add that the problem is still present in version 52.0.1
I don't think that it has something to do with the autocomplete search being slow, because I have 10 addresses in my address book.
Probably the dalay used to prevent the autocomplete to kick in too early should be lowered or removed with such a small number of contacts (and that would hide the "fast-enter" problem).
This delay wasn't present in the old autocomplete and Enter and TAB used to work well.

Comment 45

[Jorg K (CEST = GMT+2)]

Since the bug hasn't been resolved, the problem is still present. Thunderbird is a community project, so anyone who wants to fix a bug can do so. This bug here is not a high priority for the TB core team.

Comment 47

[Paolo Cavallini]

I never encountered this bug, and suddenly yesterday it appeared. 68.4.1 (64 bit) on Debian sid here

Comment 48

[fantasai]

wsmwk asked me to test on 76 Beta, and this bug is definitely occurring there with both Tab and Enter keys. I haven't noticed it on 68, though.

Comment 49

[Thomas D. (:thomas8)]

(In reply to fantasai from comment #48)

wsmwk asked me to test on 76 Beta, and this bug is definitely occurring there with both Tab and Enter keys. I haven't noticed it on 68, though.

Alex has elegantly fixed this problem for tab on bug 1659332: If you press tab very fast before there are any autocomplete results, we will trigger autocomplete's handleEnter only after waiting for the duration of the general autocomplete kickin timeout (reduced from 300 to 200s). So the topmost result will always be confirmed regardless of user speed of pressing tab. I guess something similar (or even exactly the same?) can be done for fast Enter key press, too.

Comment 50

[Thomas D. (:thomas8)]

Alex, it's a bit confusing and inconsistent now that tab will do the trick at any speed, but Enter still fails if pressed a little too fast.
Would you have time to have a go at this? Maybe what you have done for tab could work here, too?
This is your chance to grab the laurels of fixing this long-standing issue...

(In reply to Thomas D. (:thomas8) from comment #49)

(In reply to fantasai from comment #48)

wsmwk asked me to test on 76 Beta, and this bug is definitely occurring there with both Tab and Enter keys. I haven't noticed it on 68, though.

Alex has elegantly fixed this problem for tab on bug 1659332: If you press tab very fast before there are any autocomplete results, we will trigger autocomplete's handleEnter only after waiting for the duration of the general autocomplete kickin timeout (reduced from 300 to 200s). So the topmost result will always be confirmed regardless of user speed of pressing tab. I guess something similar (or even exactly the same?) can be done for fast Enter key press, too.

Comment 51

[Alessandro Castellani [:aleca]]

Sure, I'll try to find some capacity for next week.

Comment 52

[Alessandro Castellani [:aleca]]

This seems to have been solved during the improvements done to the recipient pills. Now the autocomplete picks the first available address even is it's not shown in the autocomplete dropdown.
I typed 3 letters and pressed enter as fast as possible and it always worked properly.