If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Extraneous DOCTYPE declration inserted into HTML files



MailNews Core
17 years ago
9 years ago


(Reporter: Katsuhiko Momoi, Assigned: Akkana Peck)


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3+])


(2 attachments)



17 years ago
** Observed with 8/25/2000 Win32 build with an HTML file
   created by NS6 Beta2. **

This problem was first filed by marina in NS internal bug database
since it was discovered during a localization testing process.

Here is a series of steps to reproduce the problem.

1. Using the latest build, create a JPN HTML message pasting some data
   in from Netscape Japan Home Page. (I don't think it has be
   a JPN msg but this will show you the problem at its severest.
2. Attach the file which I will be uploading next. This file
   was created by Netscape PR2/Mozilla M17.
3. Send it and then receive and try to display both the 
   body text and the attachment. 
4. Result: You can see the body text but not the attachment

Additional data:

It turns out M17/PR2 inserts the following line into HTML files
it creates:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Apparently we are having a problem when this line is in the attachment.

As an experiment, you can take the same PR2 generated HTML
file I will be atatching below and delete the above line
and then follow the same steps above and you will be able
to display the attachment. 

You can also use ISO-8859-1 HTML file created by M17 and 
get a simialr result.

Comment 1

17 years ago
Created attachment 13748 [details]
An HTML file generated by PR2/M17. Make a copy and delete the DOCTYPE definition line from the copy. Try both and see the difference.

Comment 2

17 years ago
The following is what is generated by 8/25/2000 Win32 M18 build:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head><!-- This page was created by the Gecko output system. -->

This looks strange with 2 DOPCTYPE definitions but this type
of HTML file does not cause a problem. 

Comment 3

17 years ago
You can't view this type of attachment inline but 
you can either save or open it via the attachment icon.

Comment 4

17 years ago
I don't really understand the original bug, but is it caused by the extra 3.2/EN

The output system, for some reason, adds 
<!-- This page was created by the Gecko output system. -->
if you don't set the flag OutputNoDoctype when generating the output.

Whatever reason there was for these comments is lost in the mists of antiquity,
and I think they've outlived their usefulness.  The editor can create its own
doctypes now, and the output system (unlike the editor) doesn't know enough to
be able to choose the right doctype.  I think we should remove the flag and the
code that generates the headers, and rely on the editor to set the doctype.

If anyone agrees (Beth?) and if it would fix this bug, reassign the bug to me
and argue for nsbeta3+.  Removing the extra comment and doctype is very trivial
-- ten minutes' work.  (You can test whether it would work by making sure the
OutputNoDoctype is false in nsHTMLContentSinkStream.cpp, or just removing the
code that outputs the headers there.)

Comment 5

17 years ago
No it seems to be caused by PR2/M17 doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

The current one which includes:


actually prevents this problem from happening.

Since we can display saved HTML file with Browser
and this problem happens only when such a file
is attached to a message, this seems to be a mail
problem. If you eliminate the duplicate doctype, then
we will see this problem again.  

The reason I copied akkana is because of the duplicate doctype
in the current builds.


Comment 6

17 years ago
Can anyone in Editor group tell us how often we might
find a line like:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

on web pages or in documents created by HTML editors?

If this is common, we will have a problem displaying
such an attachment to mail. If so, we need to get this considered
seriously for beta3. 

Comment 7

17 years ago
It is called the DOCTYPE statement, which is required for HTML files. It is used 
to define the level of DTD that was used to generate the page. Most HTML editors 
insert the doctype statement, so you should expect to see that quite often.

Comment 8

17 years ago
OK. Nomnating for beta3, then.
This problem will probably affect all HTML attachments 
with this DOCTYPE declaration.
Keywords: nsbeta3

Comment 9

17 years ago
Kat -- I didn't catch that there are 2 doctype statements being inserted. This 
is wrong. The doctype within the HEAD is invalid and should not be there. I 
believe Harish needs to be involved with this bug -- adding him to the list and 
sending him a sidenote.

Comment 10

17 years ago
The extra doctype and comment in the head are the ones I was talking about that
are coming from the output system.  It would be trivial to kill that code (my
preference) or to move it so that it's outside the head, if that's more correct
(but then there would still be two doctypes, and I don't think ought to be the
output system's job to insert doctypes since it doesn't have enough information
to choose the right one).

Comment 11

17 years ago
Akkana -- can you kill that output then? That indeed would be the right thing

Comment 12

17 years ago
Note please that there 2 aspects to this bug.

1. Editor is generating incorrect DOCTYPE within <HEAD> tags.
2. An attachment which contains "correct" DOCTYPE causes a display problem, and that the incorrect 
   DOCTYPE seems to be acting as a buffer for this problem. In PR2, the DOCTYPE was correctly generated
   and so HTML pages generated by PR2 when attached will cause the display problem.

That is if you fix 1, it will expose the problem in 2 more prominently. But since the correct DOCTYPE
will be generated other HTML editors, this is a problem that must be faced by the mail
component anyway. 
If someone one wants to separate these 2 issues into 2 bugs, you are welcome.

Comment 13

17 years ago
*** Bug 51320 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
I didn't realize this bug was assigned to me. Akkana, should this be re-assigned
to you to implement the changes you proposed?


17 years ago
Whiteboard: [b3 new owner?]


17 years ago
Assignee: mscott → akkana

Comment 15

17 years ago

Comment 16

17 years ago
CC'ed mscott again.

Comment 17

17 years ago
Whiteboard: [b3 new owner?] → [nsbeta3+]

Comment 18

17 years ago
Created attachment 14126 [details] [diff] [review]
Patch to stop sending out the bogus doctype

Comment 19

17 years ago
This bug is now dedicated to the DOCTYPE problem in the
editor. Changed the summary line accordingly.
The mail display problem will be filed in a new bug.
Summary: NS6 PR2 generated HTML files cause a display problem when attached to a message → Extraneous DOCTYPE declration inserted into HTML files

Comment 20

17 years ago
I've attached my diffs.  Can someone review them, please?  This should stop the
output system from including the comment and 3.2 doctype in the head.  

Meanwhile, I noticed this: The editor already has code (in editor.js) to put a
doctype as follows:
-//W3C//DTD HTML 4.01 Transitional//EN
if it doesn't see a doctype already in the file.  Is this the code that's
causing the other problem (aside from the second 3.2 doctype in the head, which
my patch fixes)?  Perhaps the JS code needs to be smarter about detecting the
language somehow (how?)
Summary: Extraneous DOCTYPE declration inserted into HTML files → NS6 PR2 generated HTML files cause a display problem when attached to a message
Target Milestone: --- → M18

Comment 21

17 years ago
Midair collision blew away someone else's change to the summary, so I'm putting
it back.
Summary: NS6 PR2 generated HTML files cause a display problem when attached to a message → Extraneous DOCTYPE declration inserted into HTML files

Comment 22

17 years ago
Fixed this part -- the output system will no longer insert the bogus 3.2 doctype
in the head, or the accompanying comment.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 23

17 years ago
Verifying this bug

Comment 24

17 years ago
Output system no longer inserts 3.2 bogus type in the head or
the accompanying comment
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.