Following up on bug 200804: Now that autocomplete continues to match once an '@' sign has been entered, there is a minor problem for identities with mail.identity._idX_.autocompleteToMyDomain = True That is: the "@domain.tld" suffix continues to be added to string the user has entered, resulting in bogus addresses: mcow@@well.com or mcow@w@well.com Steps to reproduce: 1) Set up an address book with two addresses that match on the userid. dave@somewhere.com dave@wherever.com 2) Set up an identity with 'autocompleteToMyDomain' enabled. In my case, that identity has "well.com" as the domain -- note that this shares an initial 'w' with a domain in one of the test addresses. 3) Open a compose window. Type dave@ in the first field. Observe list. 4) Type an x. Observe list. 5) Backspace, type an 's'. Observe list. 6) Backsapce, type a 'w'. Observe list. Actual results: 3) dave@@well.com <- invalid address dave@somewhere.com dave@wherever.com 4) dave@x@well.com <- invalid address 5) dave@s@well.com <- invalid address dave@somewhere.com 6) dave@w@well.com <- invalid address dave@wherever.com Expected results: 3) "dave@" => dave@well.com dave@somewhere.com dave@wherever.com 4) "dave@x" => NO COMPLETION: won't match anything, just display in red 5) "dave@s" => dave@somewhere.com <- single match: poss. no dropdown, just autofill 6) "dave@w" => dave@well.com <- auto-to-my-domain still possible match dave@wherever.com

taking.

Upgrading the severity: I've noticed that if I paste in an address that doesn't exist in my address book (or as a submatch thereof), the domain-completion is forced, appended to the address even if there's already an '@' there. A workaround is to select a different identity, paste in the address, then after completing the addressing, switch the identity back.

this fixes the problem I was able to reproduce: type a@b<tab> and get a@b@mozilla.com, if you've turned on the autoappend of the domain.

fixed on trunk and 1.8.1 branch

(In reply to comment #3) > this fixes the problem I was able to reproduce: type a@b<tab> and get > a@b@mozilla.com, if you've turned on the autoappend of the domain. Well, yes, it does that; it's a fix for the problem in comment 2, and it solves the specific usability problem I was having. I don't understand your comment about being "able to reproduce" however -- the steps I laid out are pretty straightforward. The current Actual results are similar to the previous results, except the string that formerly had domain-autocomplete appear without the @domain concatenated to it; it's still accepted verbatim if selected from the dropdown, and in that case it's still invalid. This bug originally sought to not have an invalid entry in the dropdown at all (steps 4 & 5), and also for the domain-autocompleted form to remain in the list as long as it matches what's been typed (steps 3 & 6). I'm going to reopen, and also drop the severity back down to minor.

This WFM on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081127 Lightning/1.0pre Shredder/3.0b1pre. I think we made some improvements on this recently when we migrated the autocomplete to my domain code. If someone else can verify, then I think we can close this now.

punt to Mike :)

The expected results as described above are still not achieved The actual results as originally stated changed, which I tried to describe in comment 5. There is still an invalid address shown in the dropdown list, but instead of it being autocompleted, it's just a mirror of whatever's been typed. Here's the same Actual Results, updated after David's fix. I'm seeing this in shredder 1128 as well as 2.0.0.16: Actual results: 3) dave@ <- invalid address dave@somewhere.com dave@wherever.com 4) dave@x <- invalid address 5) dave@s <- invalid address dave@somewhere.com 6) dave@w <- invalid address dave@wherever.com Expected results are unchanged.

So Neil wrote the latest version on this, cc'ing him to see if he wants to extend it a little.

I didn't really write it, all I did port the code to JS in two pieces, I started off with a port of the pre-200804 code (because I was working off an old CVS tree) and then I merged in the changes from both 200804 and this bug (although at the time I didn't notice that there were two sets of changes).

Here's how the autocomplete currently works: 1. If there are two or more addressbook or ldap results, then the popup displays all the results, including mydomain if enabled (so in this case there are actually a minimum of three results.) 2. The first addressbook or ldap match is autocompleted inline, whether or not the popup displays. 3. If all else fails and mydomain is enabled then it is autocompleted inline. For this to work a number of conditions need to hold: 1. In order to predict when to open the popup we need to know how many mydomain results there will be. In particular the mydomain result is not optional if addressbook or ldap could match. 2. If there is a mydomain result then it becomes the match of last resort. Now prior to bug 200804 no addresses containing an @ would match on any search. This meant that there were never any results and nothing would complete. However bug 200804 changed this and now there can be results matching an @. To ensure consistency of the display the mydomain result was also enabled for addresses containing an @ and this bug fixed the result to be the search string so that (as the match of last resort) it did not change the address you typed in. If the mydomain returned any other address as a result this would prevent you from typing a completely new email address, but if it returned no result at all this would prevent you from choosing between two addressbook or ldap matches. dave@x mydomain must "complete" to dave@x; there are no addressbook matches. dave@s mydomain must "complete" to dave@s; addressbook completes to dave@somewhere.com which wins but without triggering the popup. dave@w is the interesting option - it could complete to either dave@w or dave@well.com although dave@wherever.com would still win with this prefix.

Anje, could you retest using STR in comment 0 if the Actual Results are still as described in comment 8? I would like recipient autocomplete do the right thing even with "autoCompleteToMyDomain" enabled... (In reply to Mike Cowperthwaite from comment #0) > STR: > 1) Set up an address book with two addresses that match on the userid. > dave@somewhere.com > dave@wherever.com > 2) Set up an identity with 'autocompleteToMyDomain' enabled (important!!). > In my case, that identity has "well.com" as the domain -- note that this shares an > initial 'w' with a domain in one of the test addresses (important!) > 3) Open a compose window. Type dave@ in the first field. Observe list. > 4) Type an x. Observe list. > 5) Backspace, type an 's'. Observe list. > 6) Backsapce, type a 'w'. Observe list. (In reply to Mike Cowperthwaite from comment #8) > The expected results as described above are still not achieved > > The actual results as originally stated changed, which I tried to describe > in comment 5. There is still an invalid address shown in the dropdown list, > but instead of it being autocompleted, it's just a mirror of whatever's been > typed. Here's the same Actual Results, updated after David's fix. I'm > seeing this in shredder 1128 as well as 2.0.0.16: > > Actual results: > 3) dave@ <- invalid address > dave@somewhere.com > dave@wherever.com > > 4) dave@x <- invalid address > > 5) dave@s <- invalid address > dave@somewhere.com > > 6) dave@w <- invalid address > dave@wherever.com > > Expected results are unchanged.

Hi Thomas.D Windows Vista Thunderbird version 31.3.0 Running with addon 'MoreFunctionsforAddressBook'. Config Editor Settings; morecols.autocomplete.match_just_beginning; true changed setting to true: mail.identity.default.autocompleteToMyDomain;true created address book contacts as per instructions: > dave@somewhere.com > dave@wherever.com run test as per instructions. My results are : 1) dave@ <- invalid address dave@somewhere.com dave@wherever.com 2) dave@x <- invalid address 3) dave@s <- invalid address dave@somewhere.com 4) dave@w <- invalid address dave@wherever.com Retested with addons disabled - TB Safe Mode. Made sure Config Editor Settings; morecols.autocomplete.match_just_beginning; true - changed to false kept setting: mail.identity.default.autocompleteToMyDomain;true Same results. ------------------------------------- Additional info: Noticed that : mail.identity.default.autocompleteToMyDomain;true Showed the 'dave@' as invalid email address in drop down list as well as the two valid email addresses; see above, BUT nothing was offered in the autocomplete - the same place where I was typing. the TO field. but change value on mail.identity.default.autocompleteToMyDomain; false and repeat test drop down list now only shows the two valid email addresses, BUT.... it also now offers the autocomplete line in red font as: dave@ >> dave <dave@somwhere.com> This has been flagged up as a separate bug, not sure but could it help to identify where the problem lies in that bug.

(In reply to Anje from comment #13) > Hi Thomas.D > changed setting to true: > mail.identity.default.autocompleteToMyDomain;true > run test as per instructions. > My results are : > [SNIP] Thanks Anje, you rock! :) Happy New Year! As Anje pointed out, the invalid address offered is always the first entry of the autocomplete dropdown list, and it's always an exact copy of whatever the user has typed so far (invalid or valid). Offering incomplete/invalid addresses in a place where we otherwise offer only valid addresses from ABs violates ux-consistency, is useless UI, and error-prone: should be fixed per ux-error-prevention. As user types along in recipient input box... a) AutoCompleteToMyDomain works as expected when a local part of email address is entered: [dave] dave@mydomain.com []dave@somedomain.com b) However, starting from local part plus "@", the confusion starts: [dave@...] ...this is the first result shown in autocomplete dropdown > 1) dave@ <- invalid address; should still offer dave@mydomain.com > 2) dave@x <- invalid address; this should not be offered, just omit first result > 3) dave@s <- invalid address; dito > 4) dave@w <- invalid address; dito > dave@wherever.com <- other matches offered correctly > but change value on mail.identity.default.autocompleteToMyDomain; false > and repeat test > drop down list now only shows the two valid email addresses, BUT.... > it also now offers the autocomplete line in red font as: > dave@ >> dave <dave@somwhere.com> > > This has been flagged up as a separate bug, not sure but could it help to > identify where the problem lies in that bug. Do you know the bug number for the lack of inline autocomplete when this pref is true?

Anje, the next step to lure coders into fixing a bug would be to try and find a starting point in code: So in this case (informed guess), it must somehow involve the pref name: http://mxr.mozilla.org/comm-central/search?string=autocompleteToMyDomain From 14 matching files, this one looks best because it's a js file, and javascript always defines application behaviour: http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteMyDomain.js#30 30 if (this.cachedIdentity.autocompleteToMyDomain) 31 address = aString.contains("@") ? aString : 32 this.cachedIdentity.email.replace(/[^@]*/, aString); So if I understand this correctly, whenever user's typed search string (aString) contains "@", we'll return that very aString as result address (but we shouldn't). So we can take it from there and try to fix it...

And, at the bottom of http://mxr.mozilla.org/comm-central/source/mailnews/addrbook/src/nsAbAutoCompleteMyDomain.js#30, there's a footer which describes the currently viewed version, including who did the last change, and when: view http://hg.mozilla.org/comm-central/rev/[5c08b80e0daf (2014-05-05 21:39 +0300) Magnus Melin (current version)]/mailnews/addrbook/src/nsAbAutoCompleteMyDomain.js So let's CC Magnus as we go along.

(In reply to Thomas D. from comment #14) > 2) dave@x <- invalid address; this should not be offered, just omit first result Unfortunately it's not that easy. We don't want to offer the autocomplete popup if there's only one item from your address book. In the case where we don't offer your domain, this is easy: we set the popup to display if there are two or more items. However, when we do offer your domain, we set the popup to display if there are three or more items; if there is one address book match then it gets autofilled but there is no popup; if there are no address book matches then the default domain gets autofilled. So that the default domain autofill does not interfere with your typing, as soon as you type an @ it simply autofills the string you have already entered. Of course this means that if you do for some reason still have two address book matches then that string appears as the first entry in the popup. We can't omit the result as then the popup would not appear to suggest the second address book match.

(In reply to neil@parkwaycc.co.uk from comment #17) Neil, thanks for commenting! That's helpful :) > (In reply to Thomas D. from comment #14) > > 2) dave@x <- invalid address; this should not be > offered, just omit first result > > Unfortunately it's not that easy. I appreciate that, but... > We don't want to offer the autocomplete popup if there's only one item from > your address book. In the case where we don't offer your domain, this is > easy: we set the popup to display if there are two or more items. I.e. for autocompleToMyDomain=*false*, we don't show popup when there's only one result, which will just autocomplete inline, indeed. > However, when we do offer your domain, we set the popup to display if there > are three or more items; Could you point us to the place in code where that is done? So now we're talking about autocompleToMyDomain=*true*. I don't understand that logic: Why would you NOT want a popup when there are TWO results? - search string: foo (why do we not offer an inline autocompletion here?) - result1: foo@mydomain.com (autocompleToMyDomain) - result2: foo@somedomain.com (AB contact) And it doesn't seem to actually work that way, popup is shown always, see next point. > if there is one address book match then it gets > autofilled but there is no popup; Not true: As seen on Anje's results (for autocompleToMyDomain=true), we NEVER autocomplete inline and we ALWAYS show a popup even when there's ONLY the autocompleToMyDomain result. > if there are no address book matches then > the default domain gets autofilled. It does NOT get autofilled inline. > So that the default domain autofill does not interfere with your typing, as > soon as you type an @ it simply autofills the string you have already > entered. This might explain the current behaviour somewhat, but it's still bad behaviour. I wonder if we can find a better way to avoid "interference with typing"? (Perhaps involving bug 533109, bug 754265, or bug 721225?) > Of course this means that if you do for some reason still have two address > book matches then that string appears as the first entry in the popup. Dito, the result created by autocompleToMyDomain ALWAYS appears in popup, never inline (which is wrong). > We can't omit the result as then the popup would not appear to suggest the > second address book match. I don't really understand that :| Bottom line: Whatever the "technical" reason behind the current behaviour, it's wrong from an UX point of view (not badly broken, but awkward): - ux-inconsistent (we never show invalid addresses in results) - useless UI (nothing happens when you select the invalid address) - error-prone (user might select invalid address thinking it's a valid address from AB) Which makes this a case of - ux-implementation-level: > interfaces should not be organized around the underlying implementation and technology in ways > that are illogical I understand Bug 299890 also raises similar complaints; see also bug 331116, bug 1025684).

(In reply to Thomas D. from comment #18) > Dito, the result created by autocompleToMyDomain ALWAYS appears in popup, > never inline (which is wrong). Let me rephrase that: With autocompleToMyDomain=true, at least some of the *other* matches from AB should complete inline as applicable; and we should consider inline completion for autocompleToMyDomain-result, especially when it's the only result.

Sorry, that was based on my memory of how things used to work (which itself still wasn't correct since there was LDAP adding to the confusion). In fact the autocomplete newsgroup names feature required us to change it so that the popup is always shown for two matches. I therefore agree that it makes sense to hide the domain match if the email address does not correspond to it.

re: > but change value on mail.identity.default.autocompleteToMyDomain; false > and repeat test > drop down list now only shows the two valid email addresses, BUT.... > it also now offers the autocomplete line in red font as: > dave@ >> dave <dave@somwhere.com> > > This has been flagged up as a separate bug, not sure but could it help to > identify where the problem lies in that bug. > Do you know the bug number for the lack of inline autocomplete when this pref is true? This bug refers to the search parameters plus chevons issue eg: dave@ >> dave <dave@somwhere.com> https://bugzilla.mozilla.org/show_bug.cgi?id=1043310