Closed Bug 1679848 Opened 2 years ago Closed 2 years ago

Send button remains disabled in spite of valid (non-pillified) recipient address(es) and no UI clues why


(Thunderbird :: Message Compose Window, defect)



(thunderbird_esr78? fixed, thunderbird84? affected)

85 Branch
Tracking Status
thunderbird_esr78 ? fixed
thunderbird84 ? affected


(Reporter: fenimore, Assigned: aleca)



(Keywords: ux-discovery, ux-mode-error)


(2 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Create a new message and enter a single RFC 822 email address in the composer.

Actual results:

The "send" button remains grey even after entry of a single RFC 822 address. The valid RFC 822 address remains red.

Expected results:

--> The send button should unblock regardless of address-pill formation once a valid RFC 822 address is input. This constitutes failure to accept valid input and is at a minimum a UX fault.

An RFC 822 address must be valid input to a reasonable MUA interface. The "send" button activation should be tied to valid RFC 822 input in the composer window, not the internal state-representation of the pill-address. This compose-window behavior is highly discordant with RFC 822.

Scrubbed email address from image.

Attachment #9190362 - Attachment is obsolete: true
Component: Untriaged → Message Compose Window

Good points, P. F. (reporter). Xref Bug 1674054. The tricky part is that we also autocomplete on blur (which I have doubts about, see my Bug 1674054 Comment 6), so just enabling the send button for non-pillified addresses is also tricky, because we'd then autocomplete after you click the send button, with potentially unwanted results (e.g when you have typed and have in your AB). As long as we autocomplete on blur, I think we must disable send button as long as there's any non-pillified address. Which, as this bug correctly points out, is also odd. Workaround: just press tab or click anywhere else in the message to pillify on blur, then send.

See Also: → 1674054
Summary: Single RFC 822 address entry cause the compose interface "send" button to deadlock against address-pill formation → Send button remains disabled in spite of valid plain text (non-pillified) recipient address(es)
Summary: Send button remains disabled in spite of valid plain text (non-pillified) recipient address(es) → Send button remains disabled in spite of valid (non-pillified) recipient address(es)

Confirming as a UX-mode-error problem because from user's pov, there's no reason why sending with a valid email address should be prevented, and the UI gives no clues how to correct this via pillification. May not happen for everyone because it can only happen when address is the last thing you touch on your draft. But yeah, it can happen and we should probably figure out something (at least an UI hint on send button) to ease this situation, between bug 1674054 and this bug.

Ever confirmed: true
Summary: Send button remains disabled in spite of valid (non-pillified) recipient address(es) → Send button remains disabled in spite of valid (non-pillified) recipient address(es) and no UI clues why

I can take care of this, thanks for the detailed report.

Assignee: nobody → alessandro
Attached patch 1679848-enable-send.diff (obsolete) — Splinter Review

This patch takes care of updating the send button if we have any valid address typed in a field even before it's pillified.
For this to be useful and effective, it should be used alongside bug 1674054 as that patch prevents accidental data-loss.

This patch also enables the send button when multiple addresses are pasted.
A follow up bug should improve the distinction between invalid and new addresses, as the autocomplete marks both scenarios as errors, which is a bit jarring and not correct.

Attachment #9190896 - Flags: review?(mkmelin+mozilla)
Attachment #9190896 - Flags: feedback?(bugzilla2007)
Depends on: 1674054
Comment on attachment 9190896 [details] [diff] [review]

Review of attachment 9190896 [details] [diff] [review]:

::: mail/base/content/mailWidgets.js
@@ +2126,5 @@
>            this.moveFocusToPreviousElement(input);
>          });
>          input.addEventListener("keyup", event => {
> +          // Trigger the onRecipientsChanged method at every typed letter in

for every letter typed

::: mail/components/compose/content/MsgComposeCommands.js
@@ +4784,5 @@
> +      let input = row.querySelector(
> +        `input[is="autocomplete-input"][recipienttype]`
> +      );
> +
> +      if (input.value.trim().length && isValidAddress(input.value.trim())) {

no .length please. (empty string is falsy)
Attachment #9190896 - Flags: review?(mkmelin+mozilla) → review+
Attachment #9190896 - Attachment is obsolete: true
Attachment #9190896 - Flags: feedback?(bugzilla2007)
Attachment #9191145 - Flags: review+
Target Milestone: --- → 85 Branch

Pushed by
Enable send button when a valid address is typed without the necessity of pillifing it. r=mkmelin

Closed: 2 years ago
Resolution: --- → FIXED
Regressions: 1681389
See Also: → 1683064

Comment on attachment 9191145 [details] [diff] [review]

[Approval Request Comment]
Regression caused by (bug #): -
User impact if declined: The send button doesn't enable even if the user wrote a valid address which hasn't been pillified yet
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

Attachment #9191145 - Flags: approval-comm-esr78?

Comment on attachment 9191145 [details] [diff] [review]

[Triage Comment]
Approved for esr78

Attachment #9191145 - Flags: approval-comm-esr78? → approval-comm-esr78+

This still doesn't match Thunderbird version 68 behaviour:
In Thunderbird 68, if you enter h@h, the Send button is enabled. If you remove the last character leaving h@, the send button is disabled again. In version 78.6.1, once the Send button was enabled, it remains enabled, even if you remove the input completely.

Regressions: 1687431
No longer regressions: 1687431
Blocks: 1701313
You need to log in before you can comment on or make changes to this bug.