1792726 - IMAP: Quick filter body search returns results for longer search word `1234`, but nothing for shorter `123` or `234`

Status: UNCONFIRMED

(Thunderbird :: Search, defect)

Description

[martin]

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

Steps to reproduce:

Hi.
I realized that when I use Quick search field for searching in message BODY, it works wrong.
When i put to search field value 1122332072 it finds some messages.
But when i delete one number (either from begin or end) , it does not find anything, even not that previous records .
I got to some troubles because of that... (bank transaction missed) :-(
With regards
Martin

Actual results:

When I put 112233207 to Quick search field instead of 1122332072 it does not find any results

Expected results:

Filling 112233207 have to return at least those messages returned by 1122332072

Comment 1

[Thomas D. (:thomas8)]

I recall that search & pause, then changing an existing search string goes through a different code path compared to search by typing fast one-time. However, I'd hope that this only applies to extending the search phrase (which should reduce the result set, so we can start out from the previous result set and remove non-matches, something like that...).
Maybe aceman knows more?

Comment 2

[martin]

Hi Tom.
The behaviour is strange.
I did this experiment
1)Create brand new message, delete predefined content (signature etc) and manually enter 112233, enter subject as test1
2)Press Ctrl-S (don't close window)
3)Go to concepts directory (test1 is there) and enter Quick search value 112233 : test1 is NOT found (and should be)
4)Clear QuickSearch field and test1 is there.
5)Go back to message creation window, press Ctrl-S again
6)Go to concepts again, enter QuickSearch 112233 and.....test1 appears!
Voilà!
This is not the same procedure as I wrote in the first message in this discussion, but I came to it when I tried to simplify it.
And I guess that it have same reason: This has to do something with message status.
Another experiment:
Create and send a mail with 112233 to yourself
When you try to find 112233 in SENT directory, mail is not found, but it is found in received directory ...

Comment 3

[martin]

Is anybody out there?

Comment 4

[Magnus Melin [:mkmelin] (away until Aug 10)]

Is this a local folder, or IMAP?
Thomas, can you try comment 2?

Comment 5

[martin]

It is IMAP folder.
If You follow my procedure from 29.sept , then mail is stored in "concepts" directory, which is IMAP type and is visible also with WEBmail .
M

Comment 6

[martin]

BTW, primary problem when I discovered this bug happened on IMAP directory which is NOT incoming mail direstory.
New mails from incoming directory are processed by mail filter rules.
One rule do MOVE mails containing some text to final IMAP directory.
2nd rule do COPY to same final directory.
It looks that only msgs from first rule are affected by this problems, msgs created by COPY seems to be filtered correctly.
Maybe there is same reason that msgs from rule1 are affected identically as messages put to Concepts directory??

Comment 7

[chrizilla]

WFM for local folders in TB 115.6.1 64bit @ win10-64bit.
Maybe an IMAP issue.

Comment 8

[martin]

But I would guess, that QUICKfilter works with local data...? Or not?

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to martin from comment #8)

But I would guess, that QUICKfilter works with local data...? Or not?

martin, are you able to reproduce this still?

I am not able to reproduce this in imap gmail account using 140 esr on Mac.

Comment 10

[martin]

Hi.
I tried it again and at first look it worked fine.
But I found original problematic message and it still did not work. Then i copied that msg to different dir and it works fine there. It looks that directory is corrupted. I tried to repair it, but it did not helped.
It works for any chars, not only numbers.
Funny is that when I enter for instance 112233(some id number) it works,(64 records)
When I delete last char (11223), one result found.
1122- no result
112- 1 result
11-48 results
1-136 recs.
It works silly.

Comment 11

[Wayne Mery (:wsmwk)]

Thanks for the testing. That is really strange. I could imagine that happening with global search, but not with quick filter.

Did the message copy in it's entirety to the other folder?
And when skimming through the "bad" folder, do you see any messages that don't look correct, for example don't display completely?

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #11)

Thanks for the testing. That is really strange. I could imagine that happening with global search, but not with quick filter.

Did the message copy in it's entirety to the other folder?
And when skimming through the "bad" folder, do you see any messages that don't look correct, for example don't display completely?

Martin?

Comment 13

[martin]

Sorry. I was busy.
Or lazy?
I tried reproduce it again and i had problem to invoke some variants of the error.
But I got it with original number 1122332072 and provided it to test from comment10 (linked with comment6)
By now it behaves differently than previously and on other tests (comment2) works fine.
So I can confirm, that comment10 test fails same way. (for me: directory chalupa)

Comment 14

[martin]

And messages are simple short ones (1-5KB) without attachment. They seems to be uncorrupted. Message bodies (Ctrl-U) are nearly identical (only few numbers are changing) and difference is only in delivery header (different antispam setup?)

Comment 15

[Wayne Mery (:wsmwk)]

Thanks for the details.

Are you doing this on a unified folder? If if so, does the problem also reproduce on a single folder?