PR2 created HTML attachment do not display when attached to a message

NEW
Unassigned

Status

MailNews Core
Backend
P3
normal
18 years ago
10 years ago

People

(Reporter: Katsuhiko Momoi, Unassigned)

Tracking

Trunk
Future
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
** Observed with 9/6/2000 Win32 build **

This bug was split from 50821 since keeping this problem
together with that one was ebcomign too confusing.
In any case, this bug should be fixed regardless of what
we do in Bug 50821.

Problem description:

When Mozilla attaches an HTML file of certain type to a message,
you cannot either 1) see the attachment at all in some cases, or 2) see
some text part of the attachment.

To see this problem, use the attached test file (in .zip format)
in your Local Mail folder.
(Reporter)

Comment 1

18 years ago
Created attachment 14130 [details]
A .zip file containing 4 test msgs.
(Reporter)

Comment 2

18 years ago
Unzip the above file and place it into Local folder. 
There are 4 messages in it.

1. You can fully display the attachment content in only 2
   of the 4 messages. The problematic ones contain
   thw word "PR2" in it.
2. Save all the attachments as independent files. 
3. When you examine the attachment files, you will notice
   that the ones with the display problem contains
   DOCTYPE declaration and the ones without the problem
   does not. The latter was cerated by recent Mozilla
   builds while the former was created by NS6 Beta release
   build.
  
   The difference between the 2 builds is that PR2 inserted
   the correct DOCTYPE line while recent builds insert an
   extraneous one in addition. Ironically, the recent builds
   do not cause this display problem.
(Reporter)

Comment 3

18 years ago
Compare the browser display of these saved HTML
files with that of Mail view window. You will
see the difference -- some or all content is
missing from display in Mail view.
(Reporter)

Comment 4

18 years ago
Correction. The following passage is not properly worded.

"3. When you examine the attachment files, you will notice
   that the ones with the display problem contains
   DOCTYPE declaration and the ones without the problem
   does not. The latter was cerated by recent Mozilla
   builds while the former was created by NS6 Beta release
   build.
  
   The difference between the 2 builds is that PR2 inserted
   the correct DOCTYPE line while recent builds insert an
   extraneous one in addition. Ironically, the recent builds
   do not cause this display problem."

It should read as follows:

"3. When you examine the attachment files, you will notice
   that the ones with the display problem contains a single
   DOCTYPE declaration and the ones without the problem
   contain 2 DOCTYPE lines. The latter was cerated by recent Mozilla
   builds while the former was created by NS6 Beta release
   build.
  
   The difference between the 2 builds is that PR2 inserted
   the correct DOCTYPE line while recent builds insert an
   extraneous one in addition. Ironically, the recent builds
   do not cause this display problem."

Comment 5

18 years ago
Will investigate.

- rhp
Status: NEW → ASSIGNED
Target Milestone: --- → M18

Comment 6

18 years ago
What do you guys think the severity of this is? Should this be fixed before 
shipping?

- rhp
Target Milestone: M18 → M20
(Reporter)

Comment 7

18 years ago
Rich, I suspect we have some bug problem in attachment display
right now. Here's what I've found with 9/8/2000 Win32 build.

1. If the Doctype exist in an attched file (Japanese Shift_JIS and
   ASCII html files), then we don't display them inline. 
2. You can choose the attached file from the clip icon and 
   try to open it, but I could only display the ASCII HTML attachment.
   I could not display a simple Japanese HTML file even with this method.

3. So as an experiment, I attached an ASCII HTML file with DOCTYPE
   removed manually. This attachment dispalyed but it had also the
   following problem:

   a. The original file has 2 lines of bold characters. But I saw only
      the 2nd line of the file. The 1st line was not displayed at all.
   b. Another problem is that this 2nd line which is displayed is
      not in Bold type but normal type -- what happened to the
      styling!! When you open from the clip icon, you can see that
      both lines are there and in bold type.

So something is wrong even without the DOCTYPE declaration in 
an attached HTML. In addition I believe that there will be a sizable
unmber of editors which put in the DOCTYPE line at the begining of
an HTML file. 

I feel that this is probably a serious problem. 
There is also something else wrong with attachment
display as well. In sohrt, I want us to fix this problem.

We also need to gather other attachment problems of similar type.
(I found one a few days ago when I was trying to put together
a demo at the Unicode Conference -- I attached a page and
nothing showed until I removed a Javascirpt seciton of the
page -- that is our own Netscape Japan Home page! --> probably
another attachment non-display problem I need to file next.)
(Reporter)

Comment 8

18 years ago
So currently, we cannot view a Japanese HTML attachment
of this type (i.e. with the DOCTYPE declaration) unless it is
first saved as a file and then view it with Browser.
This is a big problem. We need to investigate what happens
to attachments in other encodings also.

At minimum we need to find out what is causing this 
kind of display problem. Only when we learnthe exact cause,
we will know the real severity and the extent to which
this would be a problem.

Updated

18 years ago
QA Contact: lchiang → pmock

Updated

18 years ago
Target Milestone: M20 → Future

Comment 9

18 years ago
reassigning to ducarroz
Assignee: rhp → ducarroz
Status: ASSIGNED → NEW

Comment 10

18 years ago
Assign it to myself.
QA Contact: pmock → fenella

Comment 11

18 years ago
To Esther..
QA Contact: fenella → esther
Still a problem?
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9.7

Comment 13

17 years ago
Is this still a problem and if so, did it only happen with NS6 PR2 created mail?
 If that's the case then this is probably a wontfix.
Target Milestone: mozilla0.9.7 → mozilla0.9.9
(Reporter)

Comment 14

17 years ago
Scott, le me update the status of this problem with
the current trunk. At one point, we were creating
HTML MIME part in a way that would induce this problme.

Updated

17 years ago
Keywords: nsbeta1-
Target Milestone: mozilla0.9.9 → Future

Updated

17 years ago
QA Contact: esther → trix

Comment 15

17 years ago
removing myself from the cc list
QA Contact: trix → stephend
Product: MailNews → Core

Updated

10 years ago
Assignee: ducarroz → nobody
Status: ASSIGNED → NEW
QA Contact: stephend → backend
(Assignee)

Updated

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