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



MailNews Core
19 years ago
10 years ago


(Reporter: Jim Roskind, Assigned: rhp (gone))


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT-])



19 years ago
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.


19 years ago
Assignee: ducarroz → rhp
reassign to rhp for investigation


19 years ago
Whiteboard: PDT-

Comment 2

19 years ago
marking PDT-


19 years ago
Summary: [dogfood] Using saved "draft" email changes double spaces to capped-A → [DOGFOOD] Using saved "draft" email changes double spaces to capped-A


19 years ago
Target Milestone: M13

Comment 3

19 years ago
I'll investigate.

- rhp


19 years ago
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 4

19 years ago
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

Comment 5

19 years ago
We'll try it out with today's builds.

Comment 6

19 years ago
I am unable to reproduce the problem because I cannot edit a message
from the Drafts folder. File|Load First Draft Message does nothing.

Comment 7

19 years ago
make sure you have your local profile setup to store drafts in a valid folder.

- rhp

Comment 8

19 years ago
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.


19 years ago


19 years ago
Resolution: WORKSFORME → ---

Comment 9

19 years ago
Reopening this based on the problem exists when viewing the edited message with

Comment 10

19 years ago
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


19 years ago

Comment 11

19 years ago
Will dig in further.

- rhp

Comment 12

19 years ago
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:

<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.

Comment 13

19 years ago
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

a) Create a new message
b) in the new message, enter the body text "Hello  double   space" with extra
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.

Comment 14

19 years ago
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

Comment 15

19 years ago
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


19 years ago
Whiteboard: PDT- → [PDT-]


19 years ago
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 16

19 years ago
This is all better now.

- rhp


19 years ago
QA Contact: lchiang → pmock

Comment 17

19 years ago
changing qa assigned to pmock@netscape.com


19 years ago

Comment 18

19 years ago
Verified as fixed on win32, linux, and macos using the following builds:

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.