Open Bug 570589 Opened 14 years ago Updated 10 months ago

"Search all messages" doesn't find text in mail-body with deleted attachment

Categories

(Thunderbird :: Search, defect)

defect

Tracking

(Not tracked)

REOPENED

People

(Reporter: arnimus, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [datalossy])

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4

thunderbird is unable to search the body of messages after an attached file to a message is deleted.

(i tried to reproduce it with thunderbird 3.0.6pre and a new profile but that didn't search in "sent messages" at all.)

Reproducible: Always

Steps to Reproduce:
1. write mail with body "test123" and attach an image, sent it
2. use "search all messages" for "test123", message is found
3. delete attachment from message
4. use "search all messages" for "test123", message is NOT found anymore
Could you try with 3.1RC2 ? (most search fixes went in 3.1 not 3.x)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1

wfm on windows xp (not unix, and with .txt attachment, does it matter?)

BUT the bad news is that gloda is just completely ignoring the fact that attachment has been deleted, and shows the already deleted attachment in full glamour including its contents (thread view from faceted search results).
Someone should file a new bug about that, if there isn't one yet.
(In reply to comment #2)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100608
> Lightning/1.0b2 Thunderbird/3.1
> 
> wfm on windows xp (not unix, and with .txt attachment, does it matter?)

reporter's email address bounces, so you won't know from arnimus. So WFM based on comment 2

> BUT the bad news is that gloda is just completely ignoring the fact that
> attachment has been deleted, and shows the already deleted attachment in full
> glamour including its contents (thread view from faceted search results).
> Someone should file a new bug about that, if there isn't one yet.

Thomas, can you file that?
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
(In reply to comment #2)
> wfm on windows xp (not unix, and with .txt attachment, does it matter?)
> BUT the bad news is that gloda is just completely ignoring the fact that
> attachment has been deleted, (thread view from faceted search results).

Hm. The corrected bad news is that both parts of comment 2 were made in error -> reopen.

I suppose I mixed up the two copies of my test msg, one in Sent folder (where I didn't delete the attachment), and one in inbox (where I deleted the attachment). At the heart of such confusion are bug 570787 and bug 528044, namely that we neither show location column by default nor remember it for next time when shown (grrr).

I created a new test case with STR of comment 0, and it happens as described there (including my old testcase): Global search does indeed not find body text in messages with a just deleted attachment (image.png). Thus, can't test for "Open as list" as msg with deleted attachm doesn't show up in "fancy" faceted results. If you do "open in conversation" on such a msg from its original location in folder, it will
- for my old testcase, correctly show the msg with deleted attachment (in correction of comment2).
- for my new testcase, do nothing (needs new bug, too lazy to file right now) and cause this error:

Error: Couldn't find a collection for msg: [xpconnect wrapped nsIMsgDBHdr]
Source File: chrome://messenger/content/msgHdrViewOverlay.js
Line: 2300

(In reply to comment #3)
> Thomas, can you file that?
No longer applies, as described above.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: WORKSFORME → ---
(In reply to comment 4)
Comment 4 tested on:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1
Whiteboard: needs new bug from comment 5
Component: Mail Window Front End → Search
QA Contact: front-end → search
Whiteboard: needs new bug from comment 5 → [datalossy]
OS: Linux → All
Hardware: x86 → All
Version: unspecified → 3.1
Blocks: 585094

ReChecked in version: 91.3.2 to see if bug still active.

Email had four attachments - deleted one.
Quick filter still works
Global Search - fails to find the message with attachments where one was deleted.
Find > Search Messages - works.

Exit Thunderbird.
Deleted the global-messages-db.sqlite file
Restarted and tested Global Search

Message found in Global Search.
So bug still active.

The comment #4 message from 12 years ago is confusing, but to be clear the current behavior is:
This bug erases/corrupts the "Open Message In Conversation" functionality, such that attachment-deleted messages do not appear. The rest of the messages seem to stay.

As per above, the fix is to shut down Thunderbird, delete the Thunderbird/Profiles/*/global-messages-db.sqlite file, restart Thunderbird, and then wait an hour or so. The "Tools" > "Activity Manager" window shows the status of the rebuild.

(Almost every message I send with an attachment gets the attachment deleted right after send, so the impact of this bug is constant. I wonder if there's a separate bug somewhere on an enhancement to make it easier to choose whether to save the attachments on sent emails.)

I'm not sure if this is a new workaround, or if I just newly noticed it. But I recently discovered that if you double click M to mark the message unread, and then back to read, that it reconnects the email to the previously corrupt database of the thread history, and it also reconnects the message to the search text database. (Not sure if that's essentially one and the same database or what, but it fixes both.)

So now every time I delete an attachment I have to remember to bizarrely double click M, and then, things seem ok.

Severity: normal → S3

I noticed (due to bug 1795708) that something happened with "gloda" recently. So I checked, and the behavior of this bug still seems the same.

Thankfully the bizarre workaround of double-tapping "m" after removing attachments still works to de-corrupt the search database.

You need to log in before you can comment on or make changes to this bug.