1318415 - global search indexer indexes, displays non-preferred part of multipart/alternative

Status: NEW

(Thunderbird :: Search, defect)

Description

[Jonathan Kamens]

Attachment: email message with identical text and html contents

1. Save the two attached EML files to disk.

2. Drag and drop them both into a Thunderbird folder.

3. Observe that when you view the two messages, they both have a body consisting of a single word, "valovede".

4. In the global search box, search for the word "valovede".

5. Observe how the search results only contain the message with the subject line "matching text and html".

6. Now search for the word "tnanheme".

7. Observe how the search results contain the message with the subject line "differing text and html", and that word is displayed as the message body in the search results.

The word "tnanheme" is the contents of the text/plain part of the message displayed in step 7.

You could argue that this behavior is correct because the plain and html body parts are supposed to contain identical content. However, that is often not the case. The particular case where I discovered this is one in which a particular site sends out mass mailings which they don't want to deal with formatting as plain-text, so the plain-text body part contains a generic message with a link the user can click on to view the HTML content on their web server.

I was searching for a particular keyword in this message which I knew was there because I recalled having read it, but the search results didn't show this message because the keyword was only in the text/html body part, which the indexer did not index. This is entirely unexpected behavior, and entirely incomprehensible to any user who doesn't understand what's going on behind the scenes with body parts etc.

There are two different questions here: what should be indexed, and what should be displayed in the global search results?

It would be reasonable to index _all_ body parts of a multipart/alternative message, in case they have different contents.

It would be reasonable to index the preferred body part in this context, i.e., the last body part in the message that Thunderbird knows how to parse, which is the behavior dictated by the MIME multipart/alternative standard.

It is _not_ reasonable for the indexer to index the text/plain body part when there is a later text/html body part. That's just wrong.

As for what should be displayed in the search results, arguably it should be controlled by whatever the user's current display settings are, i.e., if the user has HTML message display enabled, then the HTML body part should be displayed regardless of what was indexed, and if the user has text message display enabled, then the text body part should be displayed.

Alternatively, the same logic as above should be employed, i.e., the text displayed in the search results should be the last body part that Thunderbird knows how to parse, as per the MIME standard.

The current behavior, displaying the plain-text body part when there is a later HTML body part, is simply wrong.

Comment 1

[Jonathan Kamens]

Attachment: email message with different text and html content

Comment 2

[f_bron]

Hello. I've found recently the same bug. I just couldn't look for some text that I knew existed, and I had to use another e-mail client to find it (for reference: Apple's Mail, Spark and Windows' Mail all found it). Then I found out that it was because the specific word I was looking for, was not contained in the plain text version, but only in the HTML version.

I think this is relatively severe and makes it hard to trust TB's indexing in general. Which is a shame because I want it to remain my daily driver 🙏