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.
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 ;)
I am still seeing this on 38.2.0.
THis is still a problem after bug 1012397 was fixed. I don't think this is related to bug 1085674.
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/
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.
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.
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.
(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.
(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.
(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.
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 <firstname.lastname@example.org> add<tab> -> Address Book <email@example.com> The middle one is in particular quite a weird result. Tested on Thunderbird 38.6.0.
(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.
(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.
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
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 firstname.lastname@example.org. 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 email@example.com. 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.
(CC: Aceman: I'm revisiting these autocomplete bugs since I reviewed your bug 1290729 and had to play around with adding recipients.)
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?
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.
Would you like to take this bug, Magnus?
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.
Created attachment 8794606 [details] [diff] [review] 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?
I forgot to paste the fix from bug 1012397 here: https://hg.mozilla.org/mozilla-central/rev/ac6ad9e34835
(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.
(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.
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.
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.
(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.