Open Bug 1658157 Opened 2 years ago Updated 8 months ago

Email addresses with comma in display name cannot be entered via keyboard if they match an auto-complete result

Categories

(Thunderbird :: Message Compose Window, defect, P2)

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: jorgk-bmo, Assigned: jorgk-bmo)

References

(Blocks 1 open bug, Regression)

Details

(5 keywords, Whiteboard: [TM:78.2.0])

User Story

[Undiscoverable workaround: delete inline autocomplete suggestion before typing any comma in the new display name]

Attachments

(2 files, 3 obsolete files)

+++ This bug was initially created as a clone of Bug #1642279 +++

Have John Smith <js@example.com> in your address book.

Try to send an e-mail to Smith, James <jasm@example.com>.

It doesn't work, entering Smith, will auto-complete John.

Looks like this code
https://searchfox.org/comm-central/rev/085526b22865ea90738d779fa14bf711d46f69d3/mail/components/compose/content/addressingWidgetOverlay.js#564
isn't smart enough since the selection we test is >> John Smith <js@example.com> and that is a valid address, only that the user never entered it.

Attached patch 1658157.patch (obsolete) — Splinter Review

What do you think of this? I started coding the four cases separately, like so:

        !isValidAddress(input.value.substring(0, input.value.selectionEnd)) ||
        selection[0] == "," ||
        selection.startsWith(" >> ") ||
        // how to detect case 4??

and then it occurred to me that input.selectionStart > 0 covers it all. Am I missing something?

Assignee: nobody → jorgk-bmo
Status: NEW → ASSIGNED
Attachment #9169010 - Flags: review?(alessandro)
Attached patch 1658157.patch (v1b) (obsolete) — Splinter Review

This is better.

Attachment #9169010 - Attachment is obsolete: true
Attachment #9169010 - Flags: review?(alessandro)
Attachment #9169012 - Flags: review?(alessandro)
Attachment #9169012 - Attachment is patch: true
Attached patch 1658157.patch (v2) (obsolete) — Splinter Review

Actually, this is a whole let easier. If invalid or any autocomplete in progress, don't terminate with comma.

Attachment #9169012 - Attachment is obsolete: true
Attachment #9169012 - Flags: review?(alessandro)
Attachment #9169014 - Flags: review?(alessandro)
Attachment #9169014 - Attachment is patch: true

Comment on attachment 9169014 [details] [diff] [review]
1658157.patch (v2)

Hmm, Alex is on PTO?

Attachment #9169014 - Flags: review?(mkmelin+mozilla)

Rebased, sorry about the noise.

Attachment #9169014 - Attachment is obsolete: true
Attachment #9169014 - Flags: review?(mkmelin+mozilla)
Attachment #9169014 - Flags: review?(alessandro)
Attachment #9169028 - Flags: review?(mkmelin+mozilla)
Attachment #9169028 - Flags: review?(alessandro)
Attachment #9169028 - Attachment is patch: true
Comment on attachment 9169028 [details] [diff] [review]
1658157.patch (v2)

Review of attachment 9169028 [details] [diff] [review]:
-----------------------------------------------------------------

But then you can't autocomplete with comma, which gives inconsistent behaviour.
As bug 1138033 comment 53 points out, to achieve the wanted result, one can remove the autocomplete suggestion using Delete, and then go on typing in this unusual case. That may be enough.
Attachment #9169028 - Flags: review?(mkmelin+mozilla)
Attachment #9169028 - Flags: review?(alessandro)
Attachment #9169028 - Flags: review-

(In reply to Magnus Melin [:mkmelin] from comment #7)

But then you can't autocomplete with comma, which gives inconsistent behaviour.

Right, the patch stops auto-complete when typing a comma. That's the desired behaviour. The comma should only trigger pill creation when you've completely entered the address. I don't know what's inconsistent about that. Doing auto-complete on a comma, that is inconsistent and surprising.

Let me list the cases I had spelled out in the original version of the patch and you tell me why auto-completion would make sense here:

+      // Don't trigger autocomplete in the following cases:
+      // 1) `Doe,` was entered quickly, no autocomplete, that's not a valid address.
+      // 2) `Doe,` was entered, triggering autocomplete with `Doe, John <jd@example.com`,
+      //    selection is `, John <jd@example.com`.
+      // 3) `Doe,` was entered, triggering autocomplete with ` >> Jane Doe <jd@example.com>`.
+      // 4) `Do,` was entered, triggering autocomplete with `Doe, John <jd@example.com>`,
+      //    selection is `e, John <jd@example.com`.
+      // Cases 2) to 4) can be summarised as `input.selectionStart > 0`.

I think deleting the auto-complete suggestion/selection is not very intuitive and should only be promoted as the last resort. What do Alex and Thomas think?

Flags: needinfo?(bugzilla2007)
Attachment #9169028 - Flags: review?(alessandro)

Actually, this is worse, since no one will know when to delete the auto-complete selection.

If you have Jane Doe <jd@example.com> in the AB, typing Doe will come up with that suggestion. If you continue typing the comma, Jane will already be accepted. That's utterly wrong. You need to know before typing the comma that you need to delete the auto-complete selection. That's not obvious at all.

It's a different case to wanting to write to huhu@huhu.co when the suggestion is huhu@huhu.com with the m being selected. Then you just hit delete and be done. That's bug 1138033.

It's inconsistent within(In reply to Jorg K (CEST = GMT+2) from comment #8)

(In reply to Magnus Melin [:mkmelin] from comment #7)

But then you can't autocomplete with comma, which gives inconsistent behaviour.

Right, the patch stops auto-complete when typing a comma. That's the desired behaviour. The comma should only trigger pill creation when you've completely entered the address. I don't know what's inconsistent about that. Doing auto-complete on a comma, that is inconsistent and surprising.

It's not desired behaviour. Auto-complete on comma is how one enumerates items on one line, which is what this is about.
Gmail does it. Outlook (at least online) does it.

If we "sometimes" do it, that's inconsistent within the application.

Comment on attachment 9169028 [details] [diff] [review]
1658157.patch (v2)

And further to the inconsistency issue: After bug 1642279, the behaviour is now totally inconsistent. Depending on the auto-complete selection, entering a comma now sometimes triggers auto-complete, and sometimes it doesn't, in case the selection starts with a comma. Why is that case exempt but not the others?

Attachment #9169028 - Flags: review- → review?(mkmelin+mozilla)
Comment on attachment 9169028 [details] [diff] [review]
1658157.patch (v2)

Review of attachment 9169028 [details] [diff] [review]:
-----------------------------------------------------------------

Well, I think it makes sense to exempt the case where the comma is in the autocomplete suggestion exactly because the comma is next char is the suggestion.
Attachment #9169028 - Flags: review?(mkmelin+mozilla) → review-

(Since pEp also have an Outlook plugin, I actually have an up-to-date OL client on my machine, I'll try it.)

(In reply to Jorg K (CEST = GMT+2) from comment #8)

I think deleting the auto-complete suggestion/selection is not very intuitive and should only be promoted as the last resort. What do Alex and Thomas think?

+1. Afaics Jörg's patch attachment 9169028 [details] [diff] [review] does exactly the right thing, prevent premature autocompletion while preserving the convenience of pill creation with comma.

  • We all agree that we want to make entering addresses convenient by allowing comma to finish a pill. Thanks Magnus for keeping that on the agenda.
  • Please note the difference between comma for autocompletion and comma for pill creation!
  • As Alex and others on this bug have pointed out, we cannot prescribe/control user's input, and Doe, John <john@asdf.com> is a perfectly valid recipient input, as is Alessandro Castellani, TB UX <foo@bar.com>, "Miller, Jane, dep. 45, Anytown City Administration" <jm45@anytown.foo.com> and Koizumi, Jun'ichirō <foo@bar.com> for our friends from the East who prefer Last name first. No doubt, Thunderbird must respect the standards and provide for these everyday use cases. This isn't a matter of personal preference.
  • It follows, as Alex and others here have all agreed, that autocompletion on comma is not possible (like it or not) because it interferes with legitimate everyday input prematurely. We can't expect users to guess in advance that typing comma will suddenly hijack their input, and when it happens, it's too late.
  • Also, autocompletion on comma is not very intuitive - I am yet to see a single application which does that, so my theory is that users would not even try to autocomplete with comma. Everybody knows autocomplete suggestions must be confirmed with enter or tab to apply. Why would anyone try to type a comma when there's a pending autocomplete selection, given that every known application in this world overwrites text selections when you type another character?
  • Having to interrupt typing legitimate input before typing comma, delete an autocomplete suggestion which you haven't asked for, and then continue typing, is clearly not discoverable, highly interruptive and error-prone, so we don't want to go there.
  • That said, nothing stops us to allow pill creation on comma for user's convenience, which is what Jörg's patch does, combining convenience with standards.

In a followup bug, we'll want to ensure that isValidAddress() actually checks accurately for variants of valid recipients, and does not consider an incomplete address complete; which involves considering double quotes around display name: "Alessandro Castellani, UX-lead@TB.net, Canada" <foo@bar.com>.

I have tested gmail webmail. It just stupidly creates a pill upon typing comma, even for "Jo, you'll get "Jo (with quotation mark) as a pill - I don't think they have put any effort into allowing and ensuring valid addresses. Thunderbird must do better than that.

Whilst it's true that gmail will autocomplete the topmost autocomplete proposal when you type comma, that stops being useful behaviour when it prevents valid recipients for large real world use cases.

Flags: needinfo?(bugzilla2007)
Attached image OL-auto-complete.png

The desktop application Outlook does a far less aggressive auto-complete. It doesn't fill anything into the input area, and the user needs to explicitly click or otherwise select the suggestion. There are no suggestions based on surname or any other parts of the AB card, it's only matched by e-mail address (which is not helpful, but that's OL for you).

So Magnus, how can we resolve this issue? Thomas and I think that the proposed patch is right, we believe that Alex will share that opinion, but we'll have to see when he returns from PTO.

IMHO, auto-competing Smith, with anything with Smith in the address books is a HUGE fault of the product which will cause quite a storm when it hits the masses, especially since auto-complete used to stop when a comma was entered.

(In reply to Thomas D. from comment #15)
The UI must not allow quotes to be anything except quotes. It just doesn't work out and makes a huge mess of the area.

Like I wrote, comma for confirm is very common elsewhere too. Not supporting it would surely get way more complaints than not.

I understand you want to be able to enter "first, last" addresses. We allow that now. I don't think we need to optimize for it - it's a one time operation per recipient. And from what I can tell, not a very common operation at all: I think I've never got any email from anyone where the displayname is filled on first correspondence.

Comment on attachment 9169028 [details] [diff] [review]
1658157.patch (v2)

Review of attachment 9169028 [details] [diff] [review]:
-----------------------------------------------------------------

I see the intention here, and I agree that we should probably better optimize the generation of pills on comma, but this change breaks what we achieved in the previous patch.

Now if I type `Doe` and I get the only available autocomplete I have, which is `Doe, Jane <email>`, it doesn't matter how many times I hit comma, the pill is not created.

As reported, other email clients like Outlook and Gmail have comma autocomplete/pill generation, so we need to support and respect that.
Attachment #9169028 - Flags: review?(alessandro) → review-
User Story: (updated)
Priority: P1 → P2
Summary: Email addresses with comma in display name cannot be entered via keyboard if they match and auto-complete result → Email addresses with comma in display name cannot be entered via keyboard if they match an auto-complete result
You need to log in before you can comment on or make changes to this bug.