1627435 - Omission of trailing angled bracket clips last character of recipient pill's email address

Status: RESOLVED WONTFIX

(Thunderbird :: Message Compose Window, defect)

Description

[Thomas D. (:thomas8)]

STR

1. compose
2. type new recipient with email in angled brackets; accidentally omit the trailing bracket, press ENTER:
   John Doe <[e-mail] [sic]

Actual result

• last character of displayed email address has been clipped and replaced with trailing bracket:
  John Doe <foo@bar.d> [sic]
• upon re-editing, input box still remembers the complete input text <[e-mail], so the status of this pill between the two variants is now unclear

Expected result

• don't clip email entered by user
• just add trailing bracket if missing
• ensure that displayed email address and pill's input field value are always in sync

Comment 1

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #0)

Expected result

• ensure that displayed email address and pill's input field value are always in sync

Similar edge case problems where pill input value != pill label (highly confusing, as these are undefined states to the user):

• <[e-mail]> gets displayed as [e-mail], but the input still keeps the stale angled brackets
• editing John <[e-mail]> to become |John <[e-mail]>, [e-mail]| gets displayed as [e-mail], but the pill edit input still keeps stale [e-mail] (and some more intelligent and more preservative behaviour would be really great, we know how valid email addresses look...)

Comment 2

[Alessandro Castellani [:aleca]]

All of these use cases are extremely odd and I don't think we should cover them as we risk to over engineer this section in trying to predict what the user is typing.

type new recipient with email in angled brackets; accidentally omit the trailing bracket, press ENTER: John Doe <[e-mail]

Typing John Doe <[e-mail] gets converted to John Doe <[e-mail] <> and highlighted as a wrong address, so for me this is correct.

<[e-mail]> gets displayed as [e-mail], but the input still keeps the stale angled brackets

Why would you type an address with <[e-mail]> instead of a simple [e-mail]? That doesn't make sense for the autocomplete and those symbol gets properly stripped away, also in the input field for me as I don't see them when I edit the pill.

editing John <[e-mail]> to become |John <[e-mail]>, [e-mail]| gets displayed as [e-mail]

Once again, you're trying to input multiple addresses into one pill, which is wrong and not allowed. A pill is a single address, if a user edits a pill is to change that address, and if he tries to add multiple addresses, the pill correctly strips them away and keeps the last one.

This is a WONTFIX for me.
Magnus?

Comment 3

[Magnus Melin [:mkmelin]]

Seems to be working as it should at least on trunk.

Re inputting <[e-mail]> case, the brackets are NOT kept in the input for me.

Comment 4

[Thomas D. (:thomas8)]

Mass-changing bugs around the new recipient area (pills) from product/component MailNews Core/Composition to Thunderbird/Message Compose Window, because composition frontend code is not shared with SM. Mostly cloned from Bug 440377 which started out in MailNews Core long back.

20200614001RecipientPillsProductChangeTypeBug