Reply- to Filter dataloss when using html template

RESOLVED FIXED

Status

defect
RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: JoeS1, Assigned: Bienvenu)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 (stipe s8v4)
Build Identifier:  Thunderbird version 1.0+ (20050719)

Using the reply to filter with a mailto URL or an http link drops some of the
template data.

Reproducible: Always

Steps to Reproduce:
1.Set up a filter to reply to some citeria.
2.Use html format with a mailto url or an http link
3.Activate the reply to filter with an incoming mail

Actual Results:  
The sent html filter response drops most of the intended content

Expected Results:  
Send all the template content
Assignee: nobody → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
very weird - it's not like it drops the end of the template or anything - it
seems to drop stuff in the middle.
Status: NEW → ASSIGNED
(In reply to comment #3)
> very weird - it's not like it drops the end of the template or anything - it
> seems to drop stuff in the middle.
Yes and always related to a url,
In other variations of the template:
http://forums.mozillazine.org/viewtopic.php?p=1625029#1625029
It looks like the url recognizer is doing the damage.
I know for a fact that greater than and ampersand operators are being escaped in
scripts sent in html mail. (But thats another bug.)
I don't know enough to debug further, but I would suspect something related to:
http://www.bucksch.org/1/projects/mozilla/16507/
 
thx, Joe, yes, that code is probably involved. Ugh.
Posted patch proposed fixSplinter Review
the problem was that I wasn't resetting the offset vars each time through the
loop, so I just move the decl and init inside the loop where we read data from
the stream.
Attachment #190722 - Flags: superreview?(mscott)
Attachment #190722 - Flags: approval1.8b4?
Attachment #190722 - Flags: superreview?(mscott) → superreview+
Attachment #190722 - Flags: approval1.8b4? → approval1.8b4+
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
With test conditions as follows: 'suckatash' in subject, reply with template
https://bugzilla.mozilla.org/attachment.cgi?id=190491 and a reply-to address in
the message, the sent message contains header information as plain text, plus
the template content.
See attachments for view source info on test message and sent message.
 
This is with Winxp pro, using  Tbird version 1.0+ (20050803)
Joe, is the problem with your initial test case fixed?
(In reply to comment #11)
> Joe, is the problem with your initial test case fixed?
Yes David no data is lost, however the header data is placed in the body in
plain text before the intended reply template, just as in my recent example
which used a plain text message.
see attachment eml file.


Well, this condition seems to stem from the fact that I used the html template
to compose a message that I sent to myself. Since that message was sent, the
header info that I described above is "stuck" somewhere, and is included in the
filter message. This happens if I run the filter on a folder, or let the filter
react to an incoming message. I probably could clean my profile, or create a new
profile, but this seems to be a problem that might warrent investigation.
Should I preserve this condition, or go ahead and do what I have to do to
correct it. Or is there any file in my profile that could be adjusted to remove
the unwanted 'text' headers.
BTW I pride myself on keeping the same profile through testing the nightlies for
a few years, and jumping back and forth to branch builds, so I'd rather not
create a new profile.
Please disregard my prev comments about trash header info being sent. Somehow
the info was actaully in my template.
Everything I've tested seems to be working great now.
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.