Closed Bug 15313 Opened 25 years ago Closed 25 years ago

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

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: bugzilla)

References

Details

(Whiteboard: [PDT+])

Attachments

(1 file)

sample plain text file to reproduce the problem
17 bytes, text/plain
Details
** 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.
This is in the M11 trunk build, not M10 build, since there hasn't been any M10 builds so far today.
Status: NEW → ASSIGNED
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?
Sounds like a parser issue. I would ask Rickg or Harish
Target Milestone: M11
Rick, any Idea?
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> > > > >
Depends on: 15536
Summary: The body text disappears in plain text mail upon send → [DOGFOOD] The body text disappears in plain text mail upon send
Sounds like a dogfood bug to me. RickG, any comments?
Waiting for more data from jean-francios; the sample case he provided works correctly.
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</> </>
Blocks: 12176
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: ducarroz → buster
Status: ASSIGNED → NEW
As it's apparently a XIF problem, I reassign this bug to editor folk.
Assignee: buster → akkana
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.
Whiteboard: [PDT+]
Putting on [PDT]+ radar.
Assignee: akkana → ducarroz
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.
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.
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>
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Changing the .txt extension to .html of our temp file or default body file fix the problem. Fixed and checked in.
Blocks: 16654
QA Contact: lchiang → pmock
changing QA assigned to pmock
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.

Attachment

General

Creator:
Created:
Updated:
Size: