1653183 - Message disappears from Gloda global search results for good after detaching attachment in "Show results as list"

Status: NEW

(MailNews Core :: Database, defect)

Description

[Christian Wolkersdorfer]

Attachment: Images of searches and not finding initial e-mail

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

1. Use the search option to find an e-mail with an attachment (Image 1)
2. Detach and save the attachment in any folder
3. The e-mail with the attachment disappears from the found list (Image 2)
4. Repeat the search from 1)

Actual results:

5. The e-mail with the attachment can’t be found any more (Image 3)

Even after closing and reopening TB or after rebuilding the index of the mail account, it is not possible to find the e-mail with the search option any more. Yet, if the original folder is know, it can be found with the fast filter option (Image 4).

Expected results:

The e-mail with the attachment should still be found when searching for it, such as in step 1

This issue exists in TB since I can remember. I always thought it is my problem, but since I can repeat it with every new version of TB, it might be a TB issue.

I am using W10 home V 1909 Build 18363.900

Comment 1

[Thomas D. (:thomas8)]

Hello Christian W., thank you very much for this accurate and well-documented bug report.
As seen in screenshots of attachment 9163947 [details], reporter was using Gloda global search.
Confirming exactly as described (for 78.0b4 on Win10, reported against 68), updating summary accordingly. Nasty for those who use detach. Reported from organizational/enterprise environment, which are more likely to use this and will be more affected (--> tb-enterprise).

STR

1. Gloda global search, ensure result includes a uniquely recognizable message with attachment
2. Show results as list
3. Detach attachment of found message (from message preview of results list)
4. Observe search results, retry same search from step 1
5. For comparison, quick filter for same message in containing folder

Actual results

• step 3: After detaching, message disappears from search results
• step 4: repeating global search of step 1 fails to find the message again
• step 5: message still resides in containing folder with attachment correctly detached.

Expected results

• after detaching, message to remain in global search results and to continue to be found in global searches

Next step is to confirm for TB68 and earlier to see if this is a regression.

Comment 2

[Thomas D. (:thomas8)]

FTR, no dupes found in https://mzl.la/2OwexDm

Comment 3

[Thomas D. (:thomas8)]

Technically, detaching might involve deleting the original message (which strangely is also reported to fail for IMAP, bug 1089452), which would explain the disappearance. But we're supposed to immediately add the new message to GLODA again, not at some random point in the future (if at all). Wayne, could you CC a Gloda-versed person?

Comment 4

[Wayne Mery (:wsmwk)]

We don't currently have such a person AFAIK. But maybe Mark could offer thoughts, since conversations addon is close to this code.

Comment 5

[Mark Banner (:standard8)]

I suspect Thomas' thoughts are right - I've a feeling we do delete the message and rebuild it. That could be confusing Gloda somehow. Unfortunately I've never really looked at Gloda enough to feel I could dig into this at the current time.

Comment 6

[Christian Wolkersdorfer]

Hello FF programmer team,

Out of curiosity: has there been any development in identifying and solving this bug? I “lost” again several messages in the past weeks, because I can’t find them after removing the attachments. I tried to find a work-around – no success.

Best regards to all of you wherever you are!

Christian Wolkersdorfer

Comment 7

[Wayne Mery (:wsmwk)]

Vlad, can you reproduce this?

Comment 8

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Hello,

I attempted to reproduce this issue using Ubuntu 24&25, Windows 10&11 and macOS 15&26 using the STR provided in the Description as well as on Comment 1.

Testing was performed on the affected build from when the issue was submitted, 2020-07-14 / 20200714085438, as well as on the latest Daily build, 20260602103050. However, I was unable to reproduce the reported behaviour in either case.