Closed
Bug 21993
Opened 26 years ago
Closed 26 years ago
Signed msg creates creates horizontal rule in txt output
Categories
(MailNews Core :: Backend, defect, P3)
MailNews Core
Backend
Tracking
(Not tracked)
VERIFIED
FIXED
M13
People
(Reporter: pmock, Assigned: rhp)
Details
Attachments
(1 file)
|
16.46 KB,
text/plain
|
Details |
Build Date & Platform Bug Found:
Win32 commercial seamonkey build 1999-12-15-09-m12 installed on P166 Win98
Linux commercial seamonkey build 1999-12-15-08-m12 installed on P200 RedHat 6.1
MacOS commercial seamonkey build 1999-12-16-09-m12 installed on G3/400 OS 8.6
Overview Description:
When you reply to a signed mail message sent using the 5.0 plain text editor,
the message is quoted with misc dashes.
It does not matter if you send a HTML or plain text signed message from 4.7.
This problem does not occur if you reply using the 5.0 HTML mail editor.
Steps to Reproduce:
0) From 4.7, send a signed mail message to an account that you can retrieve
using 5.0
1) Edit your prefs.js file and set your compose_html to false so you use a plain
text editor.
2) In 5.0, retrieve your signed message
3) View the message
4) Click on the reply button
A plain text editor appears. It quotes the message but there are a bunch of
dashes.
Actual Results:
When I view the mail message in 4.7, I see the following text.
">--------------------------------------------------------------------smime.p7"
Expected Results:
It should quote the line without the dashes.
Additional Builds and Platforms Tested On:
Additional Information:
Example mail message...
Return-Path: <mookie@netscape.com>
Received: from judge.mcom.com ([205.217.237.53]) by
dredd.mcom.com (Netscape Messaging Server 4.1 Aug 9 1999
18:28:31) with ESMTP id FMUXMU00.G9H for <pmock@dredd.mcom.com>;
Thu, 16 Dec 1999 15:37:42 -0800
Received: from netscape.com ([208.12.40.175]) by judge.mcom.com
(Netscape Messaging Server 4.03) with ESMTP id FMUXMU00.SLR for
<pmock@netscape.com>; Thu, 16 Dec 1999 15:37:42 -0800
Message-ID: <38597808.8070707@netscape.com>
Date: Thu, 16 Dec 1999 15:38:48 -0800
From: mookie@netscape.com (pmock test)
User-Agent: Mozilla 5.0 [en-US] (MacOS; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Mock <pmock@netscape.com>
Subject: Re: From 4.7 plain text message 2 signed
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
replying to this mail message
Peter Mock wrote:
> This is a simple test message.
>-------------------------------------------------------------------smime.p7s
>
>
changing qa assigned to pmock@netscape.com
| Assignee | ||
Updated•26 years ago
|
Assignee: rhp → akkana
Summary: Plain Text - reply to signed mail message - misc dashes added → HTML to Text conversion of tables is incorrect
| Assignee | ||
Comment 2•26 years ago
|
||
Hi Peter,
What you are actually seeing is a table being converted to plain text. This
functionality doesn't seem to be correct.
Akkana: I'm not sure who owns the converters, but I bet this is already in the
bug system. Can you help me with finding this bug a home :-)
- rhp
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 3•26 years ago
|
||
With M12 out of the way, I finally have time to look at this! Unfortunately, I
can't seem to reproduce it. I can't send signed messages myself (I get a
message saying my certificate has expired, even though I renewed it fairly
recently; perhaps it wants a different certificate) but I copied a signed
message from someone else into a mozilla folder, viewed it with mozilla (it
correctly showed that it was signed), and replied to it in plaintext, and didn't
see any weird dashes. I did see some blank lines in the quoted html signature,
but that doesn't seem related to this issue.
There is a bug on plaintext conversion of html tables, with Ben Bucksch owns
(cc'ing), but I don't know if that's the same as this bug or not, without seeing
exactly what this bug is doing (the description "there are a bunch of dashes"
isn't very clear). If you're still seeing this, please make a folder containing
a message which shows this problem and attach it to the bug (or let me know
where I can access it). Otherwise I'll close it as worksforme.
Thanks Akkana,
I will re-test this bug shortly...and update the bug. :)
Updated•26 years ago
|
Whiteboard: awaiting pmaock to re-test
Comment 5•26 years ago
|
||
The bug akk mentioned is bug #18012 "Support tables in plaintext output", but it
depends on bug #17723 "Redesign OutputSinks", both being "M20" :-).
Update:
I just re-tested this bug on Linux commercial seamonkey build 1999-12-21-08-m12
and was able to reproduce this bug. I still see the extra dashes. It looks
like the horzontal rule was converted to dashes.
I was able to duplicate this problem using the signed mail message that sent out
by Patti Pierson from Steve Case and Pittman.
I will test Win32 and Mac next.
My linux test messages were created from 4.61.
My Mac test messages were created from 4.7.
Updated•26 years ago
|
Summary: HTML to Text conversion of tables is incorrect → Signed msg creates creates horizontal rule in txt output
Whiteboard: awaiting pmaock to re-test
Comment 9•26 years ago
|
||
I guess, it's the <hr> conversion, akk added last month or so.
If you see a hr on the html output, this has nothing to do with tables, changing
topic from "HTML to Text conversion of tables is incorrect" to "Signed msg
creates creates horizontal rule in txt output".
Clearing Status Whiteboard.
It looks like the problem is, that we generate TXT from HTML output, with is
prettied up. (Do vCards produce a similar problem?)
| Reporter | ||
Comment 10•26 years ago
|
||
I get the same results on Mac commercial seamonkey build 1999-12-21-08-m13 and
Win32 commercial seamonkey build 1999-12-21-09-m12.
I viewed the replied message from 5.0 in Communicator 4.7. It is not a display
problem. What I'm seeing in the 5.0 message pane is in the page source.
When I reply using the html mail editor, I do see a horzontial rule on the html
output.
When I reply to a mail message with a vcard using the plain text mail editor,
the vcard gets quoted.
Updated•26 years ago
|
Target Milestone: M13
Comment 11•26 years ago
|
||
Thanks for the attachments! Using them, I can now reproduce this. It may be
that the problem is that the <hr> isn't forcing newlines before and after it (it
would look more reasonable if it did, though really it would be better if mail
didn't quote that part at all) but I'll play around with it and find out exactly
what it's doing.
Marking M13.
Comment 12•26 years ago
|
||
Here's the quoted message:
<blockquote type="cite">
<b>HTML test</b><hr width="89%" size="4"><center>
<table border><tr><td><center>
<div align class="headerdisplayname">smime.p7s</div></center></td><td></td>
</tr>
</table>
</center>
<br>
</blockquote>
Putting this into a file and loading it into the editor also reproduces this
problem when you Output Text, and indeed, the problem is that plaintext
conversion isn't adding newlines before and after the hr as it should (though
personally I don't see the point of quoting "smime.p7s" either in html or
plaintext).
Comment 13•26 years ago
|
||
akk, I don't see a need for quoting "smime.p7s" either. And "<center>"?
CCing rhp.
Updated•26 years ago
|
Assignee: akkana → rhp
Status: ASSIGNED → NEW
Comment 14•26 years ago
|
||
Fix checked in -- the hr looks much better now.
But Rich: does it really make sense to quote obscure codes of an excrypted
signature, in either html or plaintext? It's meaningless to me as the user
replying to the message.
Reassigning to Rich for consideration -- if you think users really should see
this, go ahead and mark the bug fixed (the hr part is fixed).
| Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
| Assignee | ||
Comment 15•26 years ago
|
||
Good point Akkana. I no longer output information for Attachments that are
related to the encoding/etc. of email messages. This should look and behave
better now.
Note: The horizontal rule is normal because this is the text equivalent of the
HR object in HTML which is what this would look like in HTML. We put in an HR
to separate the body from the attachments.
- rhp
| Reporter | ||
Comment 16•26 years ago
|
||
Verified on win32 and linux using the following builds:
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-01-03-09-M13/sea
monkey32e.exe
ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/2000-01-03-08-
M13/netscape-i686-pc-linux-gnu.tar.gz
The horzontal ruler looks much better and we no longer quote the smime.p7m
attachment. We do quote the following text:
"This is an ENCRYPTED message. Mozilla Maildoes not support encrypted mail."
"This messages is possibly SIGNED. Mozilla does not support signed mail."
Waiting for next build of Mac before can verify.
| Reporter | ||
Comment 17•26 years ago
|
||
Verified on mac commercial build using the following build found at:
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/2000-01-04-09-M13/NSMacIn
staller-M13.sea.bin
Verifying bug as fixed.
Overall, it much better than before! There is however a minor problem with you
reply to a rich text signed message. It need a space or carriage return. I will
log a separate bug.
Comment 18•26 years ago
|
||
> We do quote the following text:
> "This is an ENCRYPTED message. Mozilla Maildoes not support encrypted mail."
> "This messages is possibly SIGNED. Mozilla does not support signed mail."
I have some I18N concerns. You can't insert this english string into a localized
version. But you can't insert a translated text either, as users with localized
versions potentially communicate with (for them) foreign correspondents.
E.g. I may want to see German text in my UI, but I don't want you to see German
text in my replys.
Comment 19•26 years ago
|
||
Ben - this is a good point. I am going to add your comments into a new bug
report. I'll cc: the int'l folks for their input.
Comment 20•26 years ago
|
||
http://bugzilla.mozilla.org/show_bug.cgi?id=23075 filed to track this.
Updated•21 years ago
|
Product: MailNews → Core
Updated•17 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•