Closed Bug 22508 Opened 25 years ago Closed 25 years ago

[DOGFOOD] Using saved "draft" email changes double spaces to capped-A

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jar, Assigned: rhp)

Details

(Whiteboard: [PDT-]) 

I've seen this in several of my emails, and I think I know the cause.

I send a message.
I move the message from a sent folder (or recieved area) to my drafts folder.
I do file->load_first_message_from_draft
I edit the message
I send the message.

Places in the message that contain double spaces are translated into an upper
case A with a "cap" atop it.
Assignee: ducarroz → rhp
reassign to rhp for investigation
Whiteboard: PDT-
marking PDT-
Summary: [dogfood] Using saved "draft" email changes double spaces to capped-A → [DOGFOOD] Using saved "draft" email changes double spaces to capped-A
Status: NEW → ASSIGNED
Target Milestone: M13
I'll investigate.

- rhp
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
I have tried all combinations of save and load and I don't see this behavior.
Would like to see if QA sees this with the recent builds.

- rhp
We'll try it out with today's builds.
I am unable to reproduce the problem because I cannot edit a message
from the Drafts folder. File|Load First Draft Message does nothing.
make sure you have your local profile setup to store drafts in a valid folder.

- rhp
Using builds 20000103 on win98,mac and linux I can reproducible as stated in
original scenrio with one exception:  The problem show up when viewing the
edited message in 4.7 not in 5.0.  jar, did you see the problem this when
viewing the message in 5.0, if so, I can't reproduce.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Reopening this based on the problem exists when viewing the edited message with
4.7
Note: I also tested this with a New Msg, it doesn't put the A with a hat in the
place of double spaces when viewing in 4.7.  I will try forward and reply
tomorrow.
Status: REOPENED → ASSIGNED
Will dig in further.

- rhp
I think this may be an issue having to do with entity conversion. When I type
in a line with double spaces, then do a Debug->Output HTML, I get:

    body>THISá ISá Aá TESTá THATá WE<br>AREá GOINGá TO<br>

in the DOS window.

Then when I send the message, the HTML I end up getting from the Editor and
sending is:

<html><head></head>
<body>THIS=A0 IS=A0 A=A0 TEST=A0 THAT=A0 WE<br>ARE=A0 GOING=A0 TO<br>THE=A0=
 FIRST=A0 TEST<br><br>-- <br>

But the =A0 is converted to garbage characters in 4.x.
I went and played with it and saw how to trigger the problem.  The trick is that
any paste into a composed message puts the message in the "vulnerable" state.
In this state, save and restore (from draft) induces the A with a hat.  To be
specific:

a) Create a new message
b) in the new message, enter the body text "Hello  double   space" with extra
sapces
c) Press save-as(draft)
d) Select your draft folder
e) do load first message from draft
f) notice that the message looks fine
g) Go to a 4.x window, and cut a two word phrase such as "exception: the" (which
is what I cut from this bug report)
h) Paste the two words into the end of the message being composed
i) click "save-as(draft)"
j) select your draft folder.
k) delete the first (old) draft
l) View the remaining draft (it looks fine)
m) Do another "load first draft" message

The message will appear with plenty of corruption.   I was asked to dump the
content tree when this happened, and this is what I got in my DOS window:

(I couldn't cut/paste, so the word ADDR is what I saw for various hex addresses)

html@ADDR refcount=6<
  head@ADDR refcount=5<
  >
  body@ADDR refcount=13<
    Text@ADDR refcount=4<Test \u00a0 double\u00a0 space>
    br@ADDR refcount=4<>
    br@ADDR refcount=11<>
    Text@ADDR refcount=17<exception:\u00a0 The>
    br@ADDR type=_moz refcount=24<>
  >
>

I did this work with todays daily comercial build.
Ok, I know what is going on here now. Believe it or not, this isn't a bug, but
I do have to change this behavior to "fix" this. What is happening is that we
are loading drafts and converting the body to UTF-8 (this is probably wrong!).
Then, we load the compose window with UTF-8 data and the double spaces look
right. When we send the messages, it has the Content-Type/charset of UTF-8 and
since Mozilla can understand UTF-8 natively, it looks fine, BUT if you look at
it with 4.x, you see the goofy characters. That is because you are viewing the
message in in ISO-8995-1 charset. If you tweak the character set menu to UTF-8,
viola, the message looks fine.

I think the fix here is to not convert to UTF-8 out of libmime for drafts, but
rather the charset of the original message. I will look into this today.

- rhp
Ok, I have a fix for this one (I think :-). In libmime, we were saying the
charset of the original messages was ALWAYS UTF-8, which is wrong. It should be
the charset of the original message, which we were parsing, but just not using.

I have a fix for this in my tree and I'll get it checked in today.

- rhp
Whiteboard: PDT- → [PDT-]
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
This is all better now.

- rhp
QA Contact: lchiang → pmock
changing qa assigned to pmock@netscape.com
Status: RESOLVED → VERIFIED
Verified as fixed on win32, linux, and macos using the following builds:
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/2000-01-06-09-M13/sea
monkey32e.exe
ftp://sweetlou/products/client/seamonkey/unix/linux_glibc/2.2/x86/2000-01-06-08-
M13/mozilla-i686-pc-linux-gnu.tar.gz
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/2000-01-06-11-M13/mozilla
-mac-M13.sea.bin

I can not reproduce this problem following jar's steps.  I checked this scenario
using the html mail editor and plain text editor.  I viewed the drafts in
seamonkey and communicator 4.7 (just to be certain).  In 4.7, my charset was set
to Western (ISO-8859-1).  In seamonkey, I did not change the character setting

I used 4.7 to check the page source of the message to verify that the message
body is not being converting to UTF-8.  The message body looks fine (no capped-A
characters) in seamonkey feature to "load first draft message" editor window.  I
also checked it in 4.7 feature to "edit message as new".

On each platform, they had the same defined "Content-Type". For html drafts, it
had the following definition:
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
For plain text drafts, it had the following definition:
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Transfer-Encoding: 7bit

In short, the draft looked fine in seamonkey and communicator 4.7.  No strange
looking characters where a space should be.

Verifying bug as fixed. :-)
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.