Bugzilla

A few things here:
1. I share the concern of comment #46 and I'd like to reiterate that changing the recipient **does NOT** trigger `onRecipientsChanged()` **at all** in TB 68. Once again, we have a custom notification for that. I understand that switching identities can trigger addition/removal of recipients, so if this is the case, then the function should trigger since recipients have changed, not in other situations where they haven't. I don't actually see the need for another bug, but be that as it may.
2. Moving a pill from To to Cc or vice versa triggers `onRecipientsChanged()` twice, which is unnecessary. `onRecipientsChanged()` should be the final notification after a "transaction" that modified the recipients.
3. This is from my wish list: If you create a new recipient manually, then `onRecipientsChanged()` should be called and `gMsgCompose.compFields.Xx` should already be populated to eliminate the need for calling `Recipients2CompFields()` in the first place.

I can live with 3. not being addressed, but I think you should look into 1. and 2. some more. That said, the patch fixes the original issue.

A few things here:
1. I share the concern of comment #46 and I'd like to reiterate that changing the EDIT:**From:** ~~recipient~~ **does NOT** trigger `onRecipientsChanged()` **at all** in TB 68. Once again, we have a custom notification for that. I understand that switching identities can trigger addition/removal of recipients, so if this is the case, then the function should trigger since recipients have changed, not in other situations where they haven't. I don't actually see the need for another bug, but be that as it may.
2. Moving a pill from To to Cc or vice versa triggers `onRecipientsChanged()` twice, which is unnecessary. `onRecipientsChanged()` should be the final notification after a "transaction" that modified the recipients.
3. This is from my wish list: If you create a new recipient manually, then `onRecipientsChanged()` should be called and `gMsgCompose.compFields.Xx` should already be populated to eliminate the need for calling `Recipients2CompFields()` in the first place.

I can live with 3. not being addressed, but I think you should look into 1. and 2. some more. That said, the patch fixes the original issue.