1779785 - If an existing address pill ("To", "Reply-To"...) is edited and then the Send button is clicked directly without closing the pill, the change will not be applied.

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Note: 91.11.0 (64-bit) - later versions are not in current Linux Mint distro, so I can't test in the latest version.

Change the "Reply to" address and immediately click "Send".

Actual results:

"Reply-To" header is stale.

Expected results:

"Reply-To" header should honor the change I make.

Note: If I change the "Reply to" address and then click into the message, and then click "Send", the change succeeds.

Comment 1

[Magnus Melin [:mkmelin]]

Do you mean you change Reply-To in in the settings? Whaterver address is to be used will be filled in the compose window and not changed after initialization. But you can of course change it in the compose window for that send instance.

Comment 2

[[e-mail]]

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

Do you mean you change Reply-To in in the settings?

I was not aware that there was a 'Reply-To Address' setting in Accounts. Thank you. I also see a 'Reply-To Address' in "Manage Identities...". That might be a better workaround, but even if so, there's still the original bug, eh?

Whaterver address is to be used will be filled in the compose window and not changed after initialization. But you can of course change it in the compose window for that send instance.

The bug occurs when I change "Reply-To" in the compose window "for that send instance".

If I change "Reply-To", then click "Send", the sent message doesn't include the change. But if I make the "Reply-To" change, then change the focus to something else, then click "Send", the sent message does include the change.

I don't know whether it's a problem with the "Reply-To" edit (left needing an event), or with the "Send" event handler (not handling a pending edit), but there's a bug somewhere there.

Comment 3

[Magnus Melin [:mkmelin]]

Thanks for the explanation. I can't reproduce in Thunderbird 102 at least.

Comment 4

[Alfred Peters [:infofrommozilla]]

I can confirm (TB102.0.3 + TB Daily) this not only for Reply-To, but for all Pills.

STR:
Open a composer an fill in all necessary fields so no dialog will prevents sending.
Create a pill (one from To, CC, Reply-To...) Foo <[e-mail]
Close that pill
Open that pill and change its content to Bar <[e-mail] without closing it.
Click the Send button.

Result: The email goes to Foo <[e-mail].

Comment 5

[[e-mail]]

Um... What is a "pill"? I don't recall using that word in my submittal.

Comment 6

[Alfred Peters [:infofrommozilla]]

"Pill" refers to the colored area in a header line that contains exactly one address.

See also:
https://support.mozilla.org/en-US/kb/addressing-email#w_adding-recipients-from-your-address-book

Comment 7

[[e-mail]]

I guess you folks know what "without closing the pill" means -- specifically, what "closing" means in that context.

My words: I click and change "Reply-To", then click "Send", and the sent message contains the stale value of "Reply-To". But if I click and change "Reply-To", then click off to something inconsequential, then click "Send", the sent message contains the fresh value of "Reply-To".

Comment 8

[Alessandro Castellani [:aleca]]

Thanks for the report, and apologies for the issue.
We have a check in place that "closes" a pill before sending. It seems that this is failing, therefore if an address pill is currently in edit mode, and the user sends the message, that pill is not closed and the address is not updated correctly.
We have an event listener attached to the "blur" of the input fields, so something might be failing: https://searchfox.org/comm-central/rev/a35c27ab8f68ca38fa1584932e5e9f5dfecfe002/mail/base/content/widgets/mailWidgets.js#1165-1185

Nicolai, could you investigate this issue please?

Comment 9

[u695164]

Yeah I will investigate this issue.

Comment 10

[u695164]

Attachment: Bug 1779785 - Update mail address pills before sending a email. r=aleca

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e8c1acf6acb7
Update mail address pills before sending a email. r=aleca

Comment 12

[Alexander Bergmann]

After quietly following this bug report for a while, today I had the chance to test the fix in Daily (2022-08-17). Unfortunately I discovered some still remaining cases, in which the pills are either not pillified or not updated:

0. Edit an existing pill and click the menu items "File -> Send Later", "File -> Send Now" or the toolbar button "Send"
   -> The pill is updated and the created message is correct (<--- This was fixed by the commited patch in this bug report!)

1. Edit an existing pill and click the menu items "File -> Save", "File -> Save As -> Draft", "File -> Save As -> Template" or the toolbar button "Save"
   -> The pill is not updated and the created message still contains the old value of the pill

2. Edit an existing pill and click any other menu item or toolbar button
   -> The pill is not updated

3. Edit an existing pill and click "File -> Close" or the window decoration "X" / "Close"
   -> The pill is not updated and the compose window is closed without asking the user whether to save the changes

The mentioned cases pretty much apply similarly to a new entry in the message header fields, which is not yet pillified.

Case (2) is also impacting add-ons in particular: When an add-on calls the API function messenger.compose.getComposeDetails() as part of a registered listener to either the API function messenger.menus.onClicked() or messenger.composeAction.onClicked(), then the returned details contain still the old values, because a new entry was not yet pillified and the edited pill was not yet updated.

When an entry in the message header fields is not yet pillified or an existing pill is edited, I think the change should be applied as soon as the user hits "Enter" or "Tab" or uses the mouse to navigate out of the field.

At the moment the keyboard navigation is working as expected, but the mouse navigation is still lacking in this regard. When you click the subject or body afterwards, then both a new entry is pillified and an edited pill is updated. But when clicking on the menubar or toolbar, neighter change is applied, i.e. a new entry is not yet pillified and an edited pill is not yet updated.

The commited patch in this bug now tried to solve the issue by calling the function updatePillsInEdit() when send later or send now are issued by the user. I think it would be better, to call the function pillifyRecipients(), whenever the focus of the message header field is lost. And make the function updatePillsInEdit() either a part of or a call from within the function pillifyRecipients().

Comment 13

[Alexander Bergmann]

I also discovered another issue, which is not directly part of this original bug report, but close enough that I am not sure, whether to open a dedicated bug report myself:

When you enter a string, e.g. "XYZ", in the message header fields, which is later to be considered "XYZ is not a valid email address", then the string is only pillified when the user actively uses the keyboard navigation via "Enter" or "Tab". I think the string should always be pillified, i.e. also when using the mouse navigation by clicking - for example - the subject, the body or the menubar or toolbar. (Of course the created pill should then show the mentioned warning regarding an invalid email address.)

Interestingly: When entering the same string, while editing an existing pill, then the change is applied as soon as the user clicks the subject or the body.

Comment 14

[Alessandro Castellani [:aleca]]

I'm gonna create a new bug with the reported issues.

Comment 15

[John Bieling (:TbSync)]

I was summoned. The only input I can give is that calling getComposeDetails() from an add-on should not trigger pillification (I did that once and it was a disaster). Besides that, I did not see a specific question directed at me. If there are still open questions, feel free to ping me again.

Comment 17

[Magnus Melin [:mkmelin]]

Comment on attachment 9288762 [details]
Bug 1779785 - Update mail address pills before sending a email. r=aleca

[Approval Request Comment]
Regression caused by (bug #): old regression from tb-pills
User impact if declined: can send with non-optimal/wrong address
Testing completed (on c-c, etc.): beta since long
Risk to taking this patch (and alternatives if risky): should be safe

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9288762 [details]
Bug 1779785 - Update mail address pills before sending a email. r=aleca

[Triage Comment]
Approved for esr102

Comment 19

[Rob Lemley [:rjl]]

Thunderbird 102.3.3:
https://hg.mozilla.org/releases/comm-esr102/rev/3a26d87b98b6