378147 - Installing thunderbird 2.0 breaks HTML message BODY filtering

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Eric van de Meerakker]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: version 2.0.0.0 (20070326)

After I upgraded to 2.0 from 1.5.0.10, some of my message filters stopped working. Specifically those filters which searched for keywords in the BODY of an HTML message. Unfortunately I receive some HTML-only status/error email message streams from several applications, which I can only distinguish based on information in the body of the HTML-formatted message...

Reproducible: Always

Steps to Reproduce:
I filter on: Subject, Sender and Body. Body searched for keyword literally copied from Message Source view.
Actual Results:  
Messages are not recognized, filter action not performed

Expected Results:  
Messages are recognized and filter action performed

Comment 1

[Magnus Melin [:mkmelin]]

Are you sure the body part is where it goes wrong? Is this filters on incoming, or after the fact (Sender is a custom header, so for that there is bug 184490)

Comment 2

[Eric van de Meerakker]

Yes, it is definitely the body. When I remove the Body part from the filter, it works OK, but I loose the ability to determine exactly what kind of message it is and so to file it appriopriately. Reading back I notice that I said I filtered on Sender, I actually filter on the From field, not a custom Sender field. (I do that too in other filters, but I haven't noticed any problems with that.)

Comment 3

[Magnus Melin [:mkmelin]]

Seem to work fine for me. Can you attach one of the msgs where it doesn't work? Save as .eml.

Comment 4

[teaman]

I agree with Eric.
I created a new filter that has two clauses...one searches Subject for a matching string.  That alone works fine.  I then add a second AND clause that searches the Body for a single word that definitely exists in the body and the filter won't even run.  I remove it and the filter runs.  Even if it doesn't find any results, it shows signs that it's running.  But add that Body clause and it shows no run activity.  I can change the string it searches the Body for and it doesn't make any difference. 

Comment 5

[Eric van de Meerakker]

Attachment: requested test case

Sorry about the delay in replying. The file I attached is a sample where filtering goes wrong. I would like to be able to filter on the body content, in this case whether "Salo" is present (in the line beginning with "Process :"

Comment 6

[David :Bienvenu]

I reproduced this. Thx for the test case. Since this appears to be a regression, I'm going to add it to our 2.0 tracking bug.

Comment 7

[David :Bienvenu]

Attachment: proposed fix

Comment 8

[Scott MacGregor]

Comment on attachment 264013 [details] [diff] [review]
proposed fix

Hey David, I'm wondering if we should extract the buffer from buf before we modify it. For some reason I thought buf.get() is supposed to return a const char *, I wonder if we might have other problems if we try to modify the buffer out from underneath the nsCString object. Then again, MSGStripQuotedPrintable never grows the string, it only shrinks it....

If we left the buffer management as it is, would calling buf.GetLength force the length to be recalculated?

While your here could you change:

buf.Truncate(buf.Length() - 1);

to buf.SetLength ? 

In the frozen linkage world I don't think .Truncate can have an argument so we'd have to fix this anyway later on...

Comment 9

[David :Bienvenu]

I meant to say that this should probably get changed on the trunk - maybe make MsgStripQuotedPrintable take a CString arg. But I was looking for a branch-safe patch to try first to land for 2.0.0.x before the major upgrade.

Comment 10

[David :Bienvenu]

Attachment: patch landed on trunk

carrying forward Scott's sr, after addressing his comment.

Comment 11

[David :Bienvenu]

Comment on attachment 264041 [details] [diff] [review]
patch landed on trunk

requesting 1.8.1.5 approval for this simple regression fix

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 264041 [details] [diff] [review]
patch landed on trunk

If this bug would prevent major upgrades for TBird maybe we should try to get it into 1.8.1.4

If this goes in after the FF tag we'll have to make sure the SeaMonkey people notice this one file difference since this might affect them

Comment 13

[Daniel Veditz [:dveditz]]

Comment on attachment 264041 [details] [diff] [review]
patch landed on trunk

Approved for 1.8.1.4, a=dveditz for release-drivers

Comment 14

[David :Bienvenu]

fixed on the branch, thx for the a=

Comment 15

[David :Bienvenu]

fix landed on the trunk yesterday...

Comment 16

[cmtalbert]

verified on branch, version 2.0.0.5pre (20070608) MacOS X.  Adding verified keyword