+++ This bug was initially created as a clone of Bug #1302472 +++ From bug 1302472 comment #26: 2) If >> is showing: Hovered popup value is still selected with <enter> or <tab>. (video: attachment 8791678 [details]). Accepted TB behaviour but apparently a bug. TB complaints in bug 1192739. From bug 1302472 comment #27: autocomplete-in-the-middle (the ">>" results) is something that exists only in TB, removing it could allow simplifying some code. I'm all-in for that, but it will require someone to evict that functionality from nsAutoCompleteController and eventual tests. I'm available to review changes, but it will require a separate bug and a decision on your side. === So let's remove the autocomplete-in-the-middle (the ">>" results)

I doubt we want to remove that. What would be a good replacement?

That >> is totally confusing and under certain circumstances, it still ends up in the message. I've had a case of this recently. I think it's best removed and we switch to completeselectedindex instead. That's what people liked about the old XPFE widget. That's also what Firefox does. Please watch attachment 8791806 [details]. If that selected the right recipient in the end, it would be perfect. Due to bug 1302472, there is a difference in behaviour now depending on whether the >> are showing or not, see bug 1302472 comment #26, cases 1) and 2). Since M-C discontinued the selection of the hovered choice with <enter> in part 1), we'd have to fix it in part 2) as well to make it consistent again. The simpler and better solution is to rip out the >> stuff altogether. I can't even figure out when I get the >> and when I don't, seems pretty random. In my address book setup, if I start entering "he" I don't get >>, but if I start with l, I get it.

You get >> when you type something that is not the start of the "complete entry". E.g. You have "Jorg K" in the address book, and you type "K".

IIRC we never used completeselectedindex with the old widget.

Maybe, but it worked that way anyway, see bug 1192739 comment #0 and bug 1303304 comment #2. Let's discuss the completeselectedindex over there.

I was just thinking this morning, the reason to have in-the-middle completion in thunderbird address fields, is likely because people either remembers part of the first name or part of the last name. So when searching "marco bonardo <somemail>" it's likely the user types "bon" and normal autofill doesn't kick in. An alternative could be to make the search component itself return the string in proper order for autofill to work as expected, without middle completion (last before first or viceversa), so in this case it would return "bonardo marco <somemail>" and autofill would do its normal job. Though probably there should be a certain coherence, so if the first result is inverted, all should be.

Thanks for the thought. Look, I raised this bug to fix this problem: 2) If >> is showing: Hovered popup value is still selected with <enter> or <tab>. (video: attachment 8791678 [details]). Accepted TB behaviour but apparently a bug. TB complaints in bug 1192739. So my brute force approach was to remove the >> stuff. I was wrong. If you turn to bug 1303304 comment #6, you can see that a combination of completedefaultindex and completeselectedindex works perfectly, even with in-the-middle completion. So let's change the summary, but if bug 1303304 goes through, we don't need the fix here. And BTW, we don't need the fix in bug 1302472 either since bug 1303304 seems to fix both issues. Marco, shall we WONTFIX this or are you interested to have your toolbox/toolkit in good shape?

(In reply to Jorg K (GMT+2, never had any PTO during summer) from comment #7) > Marco, shall we WONTFIX this or are you interested to have your > toolbox/toolkit in good shape? Bugs should be tracked until the code causing them is fixed or removed. We can avoid tracking this with an high priority though. That said, I still think in-the-middle completion is something that should be removed, since consumers have a workaround (that is to make the search component return matching text in the proper order, as explained in comment 6). And on the long term, that's where we should go, cause this "feature" adds complication we really don't want to handle.

(In reply to Marco Bonardo [::mak] from comment #8) > That said, I still think in-the-middle completion is something that should > be removed, since consumers have a workaround (that is to make the search > component return matching text in the proper order, as explained in comment 6 I don't think that is feasible, especially as the match can be on other things than the start of the words, in the email address only, or even on things not shown in the entry (like nick!).

(In reply to Magnus Melin from comment #9) > I don't think that is feasible, especially as the match can be on other > things than the start of the words, in the email address only, or even on > things not shown in the entry (like nick!). Well, what I'm saying is that the code may be changed to match only the beginning of words, makes more sense imho, it's very unlikely one would search the middle of a name or of a last name, indeed when I search for recipients I get a bunch of false positives due to that. It's also not great to match on invisible things, usually as a user I want to see why a result matched. What we do in the urlbar, where you can actually match an url/domain in the middle, is setting defaultIndex on the result ONLY if it will match at the beginning. Otherwise we set it to -1 and it won't be autofilled. It'd still be matter of changing the search component to do the best compromise.

I don't get all the technical aspects mentioned, but clearly many people search in the middle. And for address book it's not just searching on names. I count myself among them. It would be horrible if search matched only at the start of a field.

It depends on what you mean by middle, to search you I'd never search "ayn" or "er", I'd probably search "wa" or "me". it's clearly a subjective thing, without telemetry it may be hard to guess.

(In reply to Marco Bonardo [::mak] from comment #10) > Well, what I'm saying is that the code may be changed to match only the > beginning of words, makes more sense imho, it's very unlikely one would > search the middle of a name or of a last name, indeed when I search for > recipients I get a bunch of false positives due to that. > It's also not great to match on invisible things, usually as a user I want > to see why a result matched. I can assure you it's not unlikely to search elsewhere than from start of the match. First names and last names are commonly the wrong order for email addresses. Also using hidden data is not uncommon: you'd have "mom" as a nick, but your mom's email would not have "mom" in it, obviously. Also matches on the actual email address can't be addressed as you envisioned. We do down-prioritize matches in middle of words, so matches there only rise to the top if no better matches were found.

well, for now it's not critical to remove this feature, I'm mostly looking into low-hanging fruits to simplify AC code and make it more maintainable. If in-the-middle autofill is something TB can't live without, I'm not going to touch it.

I'm really sorry that I suggested to remove "autocomplete-in-the-middle" as a fix to the real problem (see summary): While autocomplete-in-the-middle (the ">>" results) is active (only completedefaultindex used [1]), hovered popup value can be confirmed with <enter> or <tab>. Confirming the hovered value was fixed for FF in bug 1292310, but it could still observed in TB before bug 1303304 changed the configuration. So there is still a bug lurking somewhere in toolkit/autocomplete. [1] Previous configuration of TB was only completedefaultindex="true".

Changing the summary. With the patch from bug 1302472 in place, the mouse-hovered popup value is always confirmed with <enter>, regardless of whether autocomple-in-the-middle (>> showing) is active.