Bug 1633205 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

The current OpenPGP implementation in Thunderbird needs to restore a subject from a decrypted message. For treating subjects with Re: in them, it uses this horrible hack:
https://searchfox.org/comm-central/rev/d9cc983e281ba4bfbb34722bb1f080124caf6263/mail/extensions/openpgp/content/ui/enigmailMsgHdrViewOverlay.js#1261

which then makes another hack necessary:
https://searchfox.org/comm-central/rev/51eaff8b48e029097e38475155cb43390a32405b/mail/extensions/openpgp/content/ui/enigmailMsgComposeOverlay.js#3936

Needless to say, that threading won't work that way.

The correct processing would be something like shown in the attached demo patch, that is stripping the Re. and instead setting the HasRe flag. You can find more details about the issue in bug 1629555 comment #13.

If you use the attached demo patch (it hacks into "Open message in a new tab") you can prepare a message in a local folder that originally didn't have a Re. to now have one. If you copy that message into an IMAP folder, the subject is carried over, the HasRe flag is lost.

The action happens in nsParseMailMessageState::FinalizeHeaders(). There in InternSubject(), NS_MsgStripRE() determines whether the header should have the HasRe flag set. This is done on the "raw" Subject: header of the message, but the subject is clobbered by calling `m_mailDB->UpdatePendingAttributes()`. You can see it in the debug between [2] and [3].

The issue is that nsImapMailFolder::SetPendingAttributes() is lacking proper flag processing with I'll add in the next patch.
The current OpenPGP implementation in Thunderbird needs to restore a subject from a decrypted message. For treating subjects with Re: in them, it uses this horrible hack:
https://searchfox.org/comm-central/rev/d9cc983e281ba4bfbb34722bb1f080124caf6263/mail/extensions/openpgp/content/ui/enigmailMsgHdrViewOverlay.js#1261

which then makes another hack necessary:
https://searchfox.org/comm-central/rev/51eaff8b48e029097e38475155cb43390a32405b/mail/extensions/openpgp/content/ui/enigmailMsgComposeOverlay.js#3936

Needless to say, that threading won't work that way.

The correct processing would be something like shown in the attached demo patch, that is stripping the Re. and instead setting the HasRe flag. You can find more details about the issue in bug 1629555 comment #13.

If you use the attached demo patch (it hacks into "Open message in a new tab") you can prepare a message in a local folder that originally didn't have a Re. to now have one. If you copy that message into an IMAP folder, the subject is carried over, the HasRe flag is lost.

The action happens in nsParseMailMessageState::FinalizeHeaders(). There in InternSubject(), NS_MsgStripRE() determines whether the header should have the HasRe flag set. This is done on the "raw" Subject: header of the message, but the subject is clobbered by calling `m_mailDB->UpdatePendingAttributes()`. You can see it in the debug between [2] and [3].

The issue is that nsImapMailFolder::SetPendingAttributes() is lacking proper flag processing which I'll add in the next patch.
The current OpenPGP implementation in Thunderbird needs to restore a subject from a decrypted message. For treating subjects with Re: in them, it uses this hack:
https://searchfox.org/comm-central/rev/d9cc983e281ba4bfbb34722bb1f080124caf6263/mail/extensions/openpgp/content/ui/enigmailMsgHdrViewOverlay.js#1261

which then makes another hack necessary:
https://searchfox.org/comm-central/rev/51eaff8b48e029097e38475155cb43390a32405b/mail/extensions/openpgp/content/ui/enigmailMsgComposeOverlay.js#3936

Needless to say, that threading won't work that way.

The correct processing would be something like shown in the attached demo patch, that is stripping the Re. and instead setting the HasRe flag. You can find more details about the issue in bug 1629555 comment #13.

If you use the attached demo patch (it hacks into "Open message in a new tab") you can prepare a message in a local folder that originally didn't have a Re. to now have one. If you copy that message into an IMAP folder, the subject is carried over, the HasRe flag is lost.

The action happens in nsParseMailMessageState::FinalizeHeaders(). There in InternSubject(), NS_MsgStripRE() determines whether the header should have the HasRe flag set. This is done on the "raw" Subject: header of the message, but the subject is clobbered by calling `m_mailDB->UpdatePendingAttributes()`. You can see it in the debug between [2] and [3].

The issue is that nsImapMailFolder::SetPendingAttributes() is lacking proper flag processing which I'll add in the next patch.

Back to Bug 1633205 Comment 0