1910477 - Subject sometimes lost when replying to a message saved in an .eml file

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Janet Gauntt]

Attachment: TBirdBugReportExample.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36

Steps to reproduce:

Windows 11, 64 bit.
(1) Locate a message coming from a gmail user saved to an .eml file
(2) Double click on the .eml file to open it in Thunderbird
(3) Click on Reply

Actual results:

The subject comes up "Re:" and is otherwise blank. But not for all such messages saved to an .eml file. For example, I can try to reproduce the problem using a saved message sent from another gmail account that I own and the subject comes up correctly on the reply. I've seen this several times in the last release or so and it seems kind of hit or miss which ones can preserve the subject and which cannot.

Expected results:

The subject line should always fill in correctly for a reply I would think. I'm attaching a zip file which contains one such .eml file that works correctly, along with one that does not. The one with the subject "Tails in Motion Courses" is an example of one that doesn't work. The one with the subject "This is the subject of this message with an attachment" does work correctly.

Comment 1

[Francesco]

Very weird, the "Tails in Motion Courses" opened from the .eml file loses its subject when replying to it. It doesn't lose the subject when forwarding, it also doesn't lose anything when importing into a folder. Removing all the header above

MIME-Version: 1.0
From: Hannah Kampa <[e-mail]>
Date: Thu, 11 Jul 2024 22:31:49 -0500
Message-ID: <[e-mail]>
Subject: Tails in Motion Courses
To: [e-mail]
Content-Type: multipart/mixed; boundary="000000000000d04333061d048579"
Content-Length: 9138

from the .eml file also fixes the issue.

It also happens with TB 115, so not a new bug.

Comment 2

[Wayne Mery (:wsmwk)]

It also happens with TB 115, so not a new bug.

Thanks for the update. Please set version to the oldest known occurence.

Comment 3

[Hartmut Welpmann [:welpy-cw]]

I encountered this as well some time ago. A fixed buffer of just 8 KB is used, so all headers beyond that point are lost when parsed in this place.

Comment 4

[Francesco]

Interesting, so if you remove lots of headers at the front, you'll catch the Subject: header. Should be easy to fix, no?

Comment 5

[Hartmut Welpmann [:welpy-cw]]

Attachment: Bug 1910477 - Fix parsing of EML files containing large headers. r=#thunderbird-reviewers

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/151ea25996a0
Fix parsing of EML files containing large headers. r=BenC

Comment 7

[Brendan Abolivier [:babolivier]]

Backed out for causing build failures: https://hg.mozilla.org/comm-central/rev/cf8fa66c437a67f9b801cfc160c6e9f16090aa54

See the failures from https://treeherder.mozilla.org/jobs?repo=comm-central&revision=1c648455532f4bb6710084287a6711eef62fbc27

[task 2024-08-05T10:21:04.323Z] 10:21:04    ERROR -  /builds/worker/checkouts/gecko/comm/mailnews/local/src/nsMsgFileHdr.cpp:58:32: error: no matching function for call to 'min'
[task 2024-08-05T10:21:04.323Z] 10:21:04     INFO -     58 |   mozilla::Buffer<char> buffer(std::min(fileSize, 500 * 1024L));
[task 2024-08-05T10:21:04.324Z] 10:21:04     INFO -        |                                ^~~~~~~~
[task 2024-08-05T10:21:04.324Z] 10:21:04     INFO -  /builds/worker/fetches/sysroot-i686-linux-gnu/usr/lib/gcc/i586-linux-gnu/8/../../../../include/c++/8/bits/algorithmfwd.h:383:5: note: candidate template ignored: deduced conflicting types for parameter '_Tp' ('int64_t' (aka 'long long') vs. 'long')
[task 2024-08-05T10:21:04.324Z] 10:21:04     INFO -    383 |     min(const _Tp&, const _Tp&);
[task 2024-08-05T10:21:04.324Z] 10:21:04     INFO -        |     ^
[task 2024-08-05T10:21:04.324Z] 10:21:04     INFO -  /builds/worker/fetches/sysroot-i686-linux-gnu/usr/lib/gcc/i586-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:3456:5: note: candidate template ignored: could not match 'initializer_list<_Tp>' against 'int64_t' (aka 'long long')
[task 2024-08-05T10:21:04.324Z] 10:21:04     INFO -   3456 |     min(initializer_list<_Tp> __l, _Compare __comp)
[task 2024-08-05T10:21:04.325Z] 10:21:04     INFO -        |     ^
[task 2024-08-05T10:21:04.325Z] 10:21:04     INFO -  /builds/worker/fetches/sysroot-i686-linux-gnu/usr/lib/gcc/i586-linux-gnu/8/../../../../include/c++/8/bits/stl_algo.h:3450:5: note: candidate function template not viable: requires single argument '__l', but 2 arguments were provided
[task 2024-08-05T10:21:04.325Z] 10:21:04     INFO -   3450 |     min(initializer_list<_Tp> __l)
[task 2024-08-05T10:21:04.326Z] 10:21:04     INFO -        |     ^   ~~~~~~~~~~~~~~~~~~~~~~~~~
[task 2024-08-05T10:21:04.326Z] 10:21:04     INFO -  /builds/worker/fetches/sysroot-i686-linux-gnu/usr/lib/gcc/i586-linux-gnu/8/../../../../include/c++/8/bits/algorithmfwd.h:388:5: note: candidate function template not viable: requires 3 arguments, but 2 were provided
[task 2024-08-05T10:21:04.326Z] 10:21:04     INFO -    388 |     min(const _Tp&, const _Tp&, _Compare);
[task 2024-08-05T10:21:04.327Z] 10:21:04     INFO -        |     ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[task 2024-08-05T10:21:04.327Z] 10:21:04     INFO -  1 error generated.
[task 2024-08-05T10:21:04.327Z] 10:21:04    ERROR -  gmake[4]: *** [/builds/worker/checkouts/gecko/config/rules.mk:676: nsMsgFileHdr.o] Error 1

Comment 8

[Hartmut Welpmann [:welpy-cw]]

Sorry, one could almost say "inspired by bug 1911076", but this is much more obvious ... Should work now, see try run.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/cb80c73ef387
Fix parsing of EML files containing large headers. r=BenC