131692 - Overzealous address-autocompletion without possibility to correct address (no way of composing to email addresses which are similar to existing addresses in AB; can't remove or correct display name of first preselected matching contact result)

Status: VERIFIED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Arthur]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020317
BuildID:    2002031721

If I try to send a mail on my imap-account to others on the same server I simply
put their username in the 'To:' field. But autocompletion is so overzealous that
it automagically adds a server. An example: I have "[e-mail]" in
the addressbook. I want to send an email to "arthur". Typing arthur in the To:
field and changing to a different field triggers autocompletion which makes the
To: field read "[e-mail]". I can't even manually truncate it, it
always gets re-completed.

Reproducible: Always
Steps to Reproduce:
1.Have an addresses in your address-book like [e-mail]
2.Have autocompletion turned on in your preferences.
3.Try to send an email to abc

Actual Results:  You won't succeed without turning autocompletion off.

Expected Results:  The autocompletion should be correctable by the user

Comment 1

[Kathleen :Brade]

confirming; I see this in my Macintosh builds and it's annoying

Comment 2

[James Rome]

I get this also. Autocompletion used to work. Now it is totally broken on the
11/05  win2k build. It is impossible to select any other than the first
selection which is always what you typed plus @yoursomain.

And trying to select one of the other displayed choices also fails. This may be
related to a bug I filed yesterday 178710 in which the to: field grabs my typing
in the message pane.

This needs to be upgraded to major.

Comment 3

[James Rome]

This has another, even worse side effect.

I autocomplete my address, and then start typing in the subject line. The typing
is then switched back to the address field.

The same thing happens when switching from the subject field to the text field.
You switch from typing the subject to typing text, and poof, they typing is back
in the subject field.

This bug needs a higher priority.

Comment 4

[Mike Cowperthwaite]

*** Bug 158133 has been marked as a duplicate of this bug. ***

Comment 5

[James Rome]

Nothing has been done on this bug.
Even in the latest builds, the autocompletion often refuses to let you change
the selection using the drop-down scroll menu.

Comment 6

[Mike Cowperthwaite]

The duplicate addresses the bug as originally reported, and provides a fix.
Comment 2 et seq are about other problems, some of which may have been fixed elsewhere.

*** This bug has been marked as a duplicate of 93453 ***

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> The duplicate addresses the bug as originally reported, and provides a fix.
> *** This bug has been marked as a duplicate of 93453 ***

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060217 SeaMonkey/1.5a] (nightly) (W98SE)

Bug 93453 did improve the behaviour (I would guess):
it is (now) possible to send to "arthur".

Yet, it is not so obvious.

Workaround case:
1. Type "arthur"
2. When autocomplete activates, press Escape
3. Press left arrow, to move the cursor
4. Press Enter to go to the next line
R. The address is still "arthur"

But, if you don't do step 3 (which there is no actual reason to do),
autocomplete will still silently change the address to "[e-mail]" at step 4.

Reopening bug...

NB: I have 'mail.autoComplete.highlightNonMatches = true' and 'mail.identity.default.autocompleteToMyDomain = false'; setting the latter to 'true' adds an "arthur@mydomain" in the autocomplete list, but is irrelevent to this bug otherwise.

Comment 8

[Daniel Kabs, reporting bugs since 2002]

I observed this problem, too, using Thunderbird version 2.0.0.4 (20070604).

How to reproduce:
(assumed you have Thunderbird as default mail application)
- open http://www.dav-kaiserslautern.de/personal/mitgliedschaft.html
- click on the first mailto link :"[e-mail]"
- Thunderbird opens with the address "[e-mail]" 
  Watch the ".del" top level domain. This results from a typo in the
  HTML text of the page.
- Try to correct the top level domain from ".del". to ".de". 

The workaround from comment #7 does NOT work for me. I have to disable address autocompletion to correct the entry.

Comment 9

[ovidiu]

very probable dupe bug 278992 (old and less active ..)

Comment 12

[Thomas D. (:thomas8)]

omg - I don't believe this really. 10 years!
And autocomplete is still so overly aggressive that you won't do a thing if autocomplete knows better than you.

What this means is: Using TB, user cannot enter a valid email address and user-defined display name into recipient fields if autocomplete for some reason sees a match there. The UX of this is horrible, and really ridiculous!

Some sample use cases

Somebody sent me a mail to my bugzilla address:
"Thomas Lastname (TB XP header search+ tags compose ++)" <[e-mail]>

For some reason, probably collected addresses from reply-all, that address including the fancy display name went into my address book, and I forgot about it. Now I am trying to send a mail to [e-mail] *without* using any display name. There's no way. Likewise, if for whatever reason I need to enter similar shorter address, e.g. [e-mail], or email@doma, TB just won't let me do it!!! Autocomplete rules entirely.

Del, Esc, Backspace, Cursor, Copy & Paste, plain Enter - all my inputs are completely ignored and autocomplete just forces its will on me. The workaround from comment 7 no longer applies. I repeat: It is not possible to enter the address I want with the display name I want, unless I delete or tweak the AB entry itself. After more than 10 years, in a program designed to handle my mail! Omg!!!

Comment 13

[Thomas D. (:thomas8)]

Similar:  Bug 135019, (bug 163103), Bug 202333, Bug 331116, (Bug 363094), Bug 369559, Bug 418192, Bug 486501, Bug 533109

Comment 15

[Wayne Mery (:wsmwk)]

perhaps Bug 486501 and its friend bug 533109 are key

Comment 19

[Thomas D. (:thomas8)]

User enters valid address, TB replaces that with forced autocompletion of unrelated address without ways of correction - imo that's dataloss (at least datalossy). Unintendedly sending to the wrong address is also compromising user's privacy.

This (and siblings) is a bad bug. Anyone with any ideas how to fix this?

Comment 20

[Thomas D. (:thomas8)]

I repeat: A mail client actively preventing users from entering certain normal and valid addresses (unless they add them to their AB first) is a bad and ridiculous failure which should be fixed asap.

(In reply to Wayne Mery (:wsmwk) from comment #15)
> perhaps Bug 486501 and its friend bug 533109 are key

Indeed, those look like suitable starting points.
Magnus?

Comment 21

[:aceman]

What is the RFC specifying addresses without @ are valid?
The compose window really expects addresses to have @. Even if we tamed autocomplete, the compose window itself will not allow you to click Send (except for "postmaster"). I don't know where this assumption comes from but that is the current state.

Comment 22

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #21)
> What is the RFC specifying addresses without @ are valid?
> The compose window really expects addresses to have @. Even if we tamed
> autocomplete, the compose window itself will not allow you to click Send
> (except for "postmaster"). I don't know where this assumption comes from but
> that is the current state.

Not sure about that.
It might fail for legitimate cases where autocomplete-to-domain pref is true, need to test.
But other definitely legitimate cases also fail:

Having this in AB:

[e-mail]

you cannot address mail to 

[e-mail]

See my comments on bug 844614.

Comment 23

[Joshua Cranmer [:jcranmer]]

(In reply to :aceman from comment #21)
> What is the RFC specifying addresses without @ are valid?

They're not valid. There's a somewhat common UX theme among email clients that domain-less email addresses get converted to your local domain (e.g., if my email were [e-mail], then sending email to user would get converted to [e-mail]). In any case, they get converted before touching the wire.

Comment 24

[Thomas D. (:thomas8)]

(In reply to Joshua Cranmer [:jcranmer] from comment #23)
> (In reply to :aceman from comment #21)
> > What is the RFC specifying addresses without @ are valid?
> 
> They're not valid. There's a somewhat common UX theme among email clients
> that domain-less email addresses get converted to your local domain (e.g.,
> if my email were [e-mail], then sending email to user would get
> converted to [e-mail]). In any case, they get converted before
> touching the wire.

Which means that for this bug, addresses without @ are valid inputs that must not be overwritten, especially if this pref is set to true:
mail.identity.default.autocompleteToMyDomain;false
In current behaviour, shorter things are always overwritten if contained in longer things in AB.

These bugs are a bit unsorted, but we definitely have normal valid cases that fail miserably, see e.g. Bug 486501 Comment 10 (which might be an instance of bug 533109, involving copy and paste).

I think we'd want to fix clear cases like  Bug 486501 and its friend bug 533109 first.

Comment 25

[:aceman]

(In reply to Thomas D. from comment #24)
> Which means that for this bug, addresses without @ are valid inputs that
> must not be overwritten, especially if this pref is set to true:
> mail.identity.default.autocompleteToMyDomain;false
> In current behaviour, shorter things are always overwritten if contained in
> longer things in AB.

If I write a string I the autocomplete list offers the string appended with the current domain and also other things found in AB. So there is the right address that you actually want. At least in TB24.

I am not sure if mail.identity.default.autocompleteToMyDomain affects anything (outside of identity creation), because I have all the identity specific mail.identity.idX.autocompleteToMyDomain set to true even if mail.identity.default.autocompleteToMyDomain=false.

So for the original report that has "[e-mail]" in AB and want to send to "arthur", autocompleting to "[e-mail]" seems like the right thing to do. That address is correct and CAN be written (is even offered with mail.identity.idX.autocompleteToMyDomain=true) inside the compose window. So what am I missing?

Comment 26

[Magnus Melin [:mkmelin]]

The solution here is probably to have forcecomplete=false for the composition autocomplete widget. We should investigate if that's good once the other current autocomplete issues have been fixed...

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Textbox_%28Toolkit_autocomplete%29#a-forcecomplete
 "If true, the textbox will be filled in with the best match when it loses the focus. If false, it will only be filled in when the user selects an item."

Comment 27

[Guy McArthur]

Was just bitten by this bug, pasting in (e.g.) [e-mail] (who is not in the database) and Thunderbird changes it to [e-mail] (who is)... and there is no way around it!

Thunderbird 31.8.0.

Comment 28

[Charles]

(In reply to Guy McArthur from comment #27)
> Was just bitten by this bug, pasting in (e.g.) [e-mail] (who is
> not in the database) and Thunderbird changes it to [e-mail] (who
> is)... and there is no way around it!

Actually there is... just add a comma after the address (as if you were going to add another one)...

But I agree this needs to be fixed asap...

Comment 29

[Wayne Mery (:wsmwk)]

With both version 68 and 78 I am unable to reproduce this issue. A simple backspace/delete ends the autocomplete

Comment 30

[Thomas D. (:thomas8)]

(In reply to Wayne Mery (:wsmwk) from comment #29)

With both version 68 and 78 I am unable to reproduce this issue. A simple backspace/delete ends the autocomplete

Yes, I have re-tested a number of cases from this bug on Daily 81.0a1 (2020-08-07) (64-bit) and they all work using backspace/delete to get rid of inline autocompletion. Also manually fixing display names works.