Closed Bug 1777858 Opened 3 years ago Closed 3 years ago

Default CC or BCC not respected

Categories

(Thunderbird :: Message Compose Window, defect)

Thunderbird 102
defect

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 1777683

People

(Reporter: maurizio.munafo, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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

Steps to reproduce:

  • Check "CC these email addresses:" in Account Settings
  • Fill the address field with an email address
  • Write a new message or reply to an old one

Actual results:

The "CC these email addresses:" options in "Account Settings"->Account->"Copies & Folders" are not pre-filled when opening the Compose Window, when composing a new message, or when replying to a message you were not already among the CC recipients.

The empty field row is shown, as if the address field was blank in the settings. Unchecking the option correctly hides the field row.

Expected results:

Until the previous versions, the "CC these email address:" option was respected and when composing a message the field was always correctly filled in.

Thomas, can you reproduce?

Flags: needinfo?(bugzilla2007)

(In reply to Alessandro Castellani [:aleca] from comment #1)

Thomas, can you reproduce?

Wfm on 102.0 (64-bit), Win 10 - tested the following scenarios:

  • writing a new message with default identity with auto-cc
  • reply using default identity with auto-cc
  • changing identity to an identity with auto-cc

Maurizio, pls note that if you have your auto-cc'ed address somewhere amongst the To-recipients, it won't be auto-added to CC again, but indeed an empty CC row may appear (as you reported). Can you check if that's your scenario?
Similarly, if an auto-bcc'ed address is already in CC, it won't appear. The idea is to avoid duplicate addresses, and to avoid users thinking that an address is a hidden recipient when indeed it's not because it's already visibly included in To or CC.

Otherwise, can you please check if your scenario is covered by Bug 1699159?

Flags: needinfo?(bugzilla2007)

Closing wfm for now per my comment 2.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME

needinfo?reporter for my comment 2.

Flags: needinfo?(maurizio.munafo)

(In reply to Thomas D. (:thomas8) from comment #2)

(In reply to Alessandro Castellani [:aleca] from comment #1)

Thomas, can you reproduce?

Wfm on 102.0 (64-bit), Win 10 - tested the following scenarios:

I'm on 102.0 (64-bit) macOS 12.4 Monterey

  • writing a new message with default identity with auto-cc

From: preset - To: Cc: Subject: empty

  • reply using default identity with auto-cc
    From: preset - To: and Subject: set - CC: empty
  • changing identity to an identity with auto-cc

This switches to the auto-cc. But only if the identity was not the default one. Starting from the default auto-cc identity, then switch to a not default not auto-cc one, and than back to the default one works.

Maurizio, pls note that if you have your auto-cc'ed address somewhere amongst the To-recipients, it won't be auto-added to CC again, but indeed an empty CC row may appear (as you reported). Can you check if that's your scenario?

The empty CC row always appears, also any new message with no recipient yet.

Similarly, if an auto-bcc'ed address is already in CC, it won't appear. The idea is to avoid duplicate addresses, and to avoid users thinking that an address is a hidden recipient when indeed it's not because it's already visibly included in To or CC.

I don't use auto-bcc

Otherwise, can you please check if your scenario is covered by Bug 1699159?

It does not look like that Bug 1699159 is involved, since the issue is when writing a new messages and it's apparently solved when switching identities.

Maurizio

Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---

I'm experiencing the same behaviour ( 102.0 (64-Bit) on Windows 10, TB started in -safe-mode, all extensions deactivated):

  • configured address in auto-bcc
  • new mail: bcc field is there, but remains empty

If I switch to another identity the bcc field of that identity is filled, if I switch back to the first identity, the bcc is also filled correctly.

Do you have OpenPGP enabled?

(In reply to Alessandro Castellani [:aleca] from comment #7)

Do you have OpenPGP enabled?

Yes. Even disabling it, no changes in the behavior.
Tried starting in Troubleshoot Mode, no changes.

M.

Flags: needinfo?(maurizio.munafo)
Blocks: tb102found

Do you have S/MIME? Probably dupe of bug 1777683

I have S/MIME configured, but if I do not use it (no default signing or encryption).

Don't think it's directly related to bug 1777683, since, as far as I understand from the original submission, that was related to replied messages, while this bug is also and mainly about new messages.

If I compose a new message from a profile with no S/MIME configuration, and auto-cc, I still get the same empty cc: issue.

(In reply to maurizio.munafo from comment #10)

I have S/MIME configured, but if I do not use it (no default signing or encryption).

Don't think it's directly related to bug 1777683, since, as far as I understand from the original submission, that was related to replied messages, while this bug is also and mainly about new messages.

Bug 1777683 would certainly have the potential to affect new messages, too.

If I compose a new message from a profile with no S/MIME configuration, and auto-cc, I still get the same empty cc: issue.

On the "profile with no S/MIME configuration", did you completely remove the certificates so that input fields are blank as seen in the screenshot?

Flags: needinfo?(maurizio.munafo)

You are right. I actually had S/MIME configured for all my common accounts (even if I did not realize it).
When using an alt account with no S/MIME info attached, the auto-cc works in new messages.

Flags: needinfo?(maurizio.munafo)

It works in 102.0.2

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: