[DOGFOOD] The body text disappears in plain text mail upon send

VERIFIED FIXED in M11

Status

MailNews Core
Composition
P3
blocker
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: Katsuhiko Momoi, Assigned: Jean-Francois Ducarroz)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
** observed with 9/30/99 Win32 build **

This problem may be related to Bug 15265 but instead of cramming
this into that one, I decided to file a new bug.

In spite of the problem in 15265, you can actually send mail
but without the subject header.
This problem has to do with Plain Text body. Whatever input I put in
the body disappears and I get only an empty body in plain text mail.
It does not matter if the input is ASCII or non-ASCII. Also the
pre-set text disappears, too.
For HTML mail, this is not the case, however.

Comment 2

19 years ago
This is in the M11 trunk build, not M10 build, since there hasn't been any M10
builds so far today.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 3

19 years ago
The problem is that for some reason layout doesn't add anymore a body tag to the plain text file we load into Ender.
Therefore Ender failed while looking for the HTML tag BODY in nsEditor::BeginningOfDocument and in
nsTextServicesDocument::GetBodyNode.

This doesn't append with the build 9-29-M11.

Troy, any suggestion?

Comment 4

19 years ago
Sounds like a parser issue. I would ask Rickg or Harish
(Assignee)

Updated

19 years ago
Target Milestone: M11
(Assignee)

Comment 5

19 years ago
Rick, any Idea?
(Assignee)

Comment 6

19 years ago
in build from the 9-29, when I dump the content of the default plain text
message body (menu debug), I get the following output:

==============  Content Tree: ================
html refcount=3<
  head refcount=2<
  >
  Text refcount=3<\n>
  body style=white-space: -moz-pre-wrap; width: 72ch; font-family: -moz-fixed; b
ackground-color: rgb(255,255,255);  refcount=3<
    Text refcount=9<-- \n\n   This message was sent by Messenger 5.0 \n>
  >
>

With the today's build, I get:

==============  Content Tree: ================
html refcount=3<
  head refcount=2<
  >
   bgcolor=white refcount=3<
     bgcolor=white refcount=3<
       face=courier size=-1 refcount=3<
         refcount=3<>
        Text refcount=3<-- \n\n   This message was sent by Messenger 5.0 \n>
      >
    >
  >
>
(Assignee)

Updated

19 years ago
Depends on: 15536

Updated

19 years ago
Summary: The body text disappears in plain text mail upon send → [DOGFOOD] The body text disappears in plain text mail upon send

Comment 7

19 years ago
Sounds like a dogfood bug to me. RickG, any comments?

Comment 8

19 years ago
Waiting for more data from jean-francios; the sample case he provided works
correctly.
(Assignee)

Comment 9

19 years ago
Created attachment 2020 [details]
sample plain text file to reproduce the problem
(Assignee)

Comment 10

19 years ago
Rick, I reproduce the problem either on my Mac or on my PC with a debug build
from this morning (around 11 am).

Steps:

1) start apprunner
2) select menu tasks\editor or tasks\plaintext editor
3) from the editor window, open sample.txt (attached to this bug report)
4) the file correctly load into a new window but if you try to output the text,
nothing! (menu debug\output text
5) menu debug\output html gives (blank line stripped):
Getting HTML

<html>
<head>
</head>
< bgcolor="white">
< bgcolor="white">
< face="courier" size="-1">sample plain text</>
</>

Updated

19 years ago
Blocks: 12176

Comment 11

19 years ago
What we know so far is that this isn't directly a layout/parser problem. If you
load this sample page, it renders correctly. When you got to save, however,
something is lost, so I suspect it's in the XIF translation. I'll take a quick
look, but it will most likely need a review from the ender folks.
(Assignee)

Updated

19 years ago
Assignee: ducarroz → buster
Status: ASSIGNED → NEW
(Assignee)

Comment 12

19 years ago
As it's apparently a XIF problem, I reassign this bug to editor folk.

Updated

19 years ago
Assignee: buster → akkana

Comment 13

19 years ago
JF: I didn't actually see a comment from rickg saying it was xif, so I assumed
you talked with him to determine this?  Assuming this is true, assigning to
Akkana.

Updated

19 years ago
Whiteboard: [PDT+]

Comment 14

19 years ago
Putting on [PDT]+ radar.

Updated

19 years ago
Assignee: akkana → ducarroz

Comment 15

19 years ago
This has nothing to do with XIF.  The document in the content tree doesn't have
a body, so the editor doesn't consider it a valid tree and won't output it.

I can change the output routines so that we will output text nodes even if there
is no body tag (I've filed bug 16684 on that issue); but that's not the right
solution for plaintext mail, which relies on having a body tag for lots of other
things, such as wrapping (which is done via a style tag on the body).  So mail
compose needs to get that body tag back into the document.

Perhaps the editor needs a special method added to its API to read in a
plaintext file and add the necessary html nodes around it?  Or should that live
in the parser?  J-F, what call are you currently using to read in the plain
text?  If it's decided that the editor needs to add this method to its API, I
can add it.
(Assignee)

Comment 16

19 years ago
Akkana, you should contact directly Rick G. and try to find the real solution to
the problem! Everything was working fine until something change either in Layout
or in Editor between 9-29 and 9-30.

MsgCompose uses nsIEditorShell.GetContentsAs("text/plain",
nsIDocumentEncoder::OutputFormatted, ...) to retreive the plain text data.

Comment 17

19 years ago
I've just confirmed that the document is perfectly formed in both viewer and
mozilla. I've verified this using debug:dump content in viewer and the DOM
viewer in mozilla. In all cases, we see this:

<html>
<head></head>
<body>
  plain text
</body>
</html>

Comment 18

19 years ago
Rick and I compared notes -- the way I was reproducing it was:
- paste the url for the attachment for this bug into an apprunner browser window
- do file->edit page (the text renders fine)
- from the editor window, do Debug->Dump Content Tree and see that there's no
body tag

Rick later commented in mail:

After diligently working out the finer details with Akkana, I believe the
problem with this bug is that you're sending us your content with the mime-type
text/plain, and it needs to be text/html. FYI: text/plain is now treated as an
XML application.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 19

19 years ago
Changing the .txt extension to .html of our temp file or default body file fix the problem.

Fixed and checked in.

Updated

19 years ago
Blocks: 16654

Updated

19 years ago
QA Contact: lchiang → pmock

Comment 20

19 years ago
changing QA assigned to pmock

Updated

19 years ago
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.