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

newlines outside </body> are inserted inside the body node

VERIFIED FIXED in M14

Status

()

Core
HTML: Parser
P3
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Akkana Peck, Assigned: harishd)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
If the source html file has a newline after the body (which I would assume that
most do), the parser inserts that newline as a text node inside, rather than
outside, the body node in the content tree.

The easiest way to see this is to run the editor on the file
htmlparser/tests/outsinks/simple.html, then do a Debug->Dump Content Tree (or do
the equivalent debug action in viewer).  Note the three adjacent newlines near
the end but inside the body node; from the source file, they should be two
adjacent newlines inside the body plus another newline outside the body.

For extra credit, it would be nice to get the right number of newlines after the
</html>, but I can live without that and special-case it in the output sink; I
could special-case a newline after the </body> tag, too, if necessary. But I
can't detect that the extra newline node shouldn't be there inside the body, so
the output will show an extra newline before the </body> tag where there
shouldn't be one.
(Reporter)

Updated

18 years ago
Summary: newlines after </body> are inserted inside the body node → newlines outside </body> are inserted inside the body node
(Reporter)

Comment 1

18 years ago
I'm guessing this is the same problem as the longstanding problem of newlines in
the head getting inserted into the body node.  For instance, the sample
attachment to bug 15674:

 <!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html40/loose.dtd">

<html>

<head>
<title>An Example</title>
</head>

<body>
<h1>Test</h1>

</body>
</html>

gets parsed into this tree:

html refcount=4<
  head refcount=3<
    title refcount=3<
      Text refcount=3<An Example>
    >
  >
  Text refcount=4< \n\n\n\n\n\n>
  body refcount=4<
    Text refcount=4<\n>
    h1 refcount=4<
      Text refcount=8<Test>
    >
    Text refcount=4<\n\n\n\n>
  >
>

and there's no way for the output routines to know which of these are valid body
newlines and which are not, so they all go into the output.
This seems like bug 12998 at the opposite end...
(Reporter)

Comment 3

18 years ago
Yes, it does look like a dup of 12998.  That one is marked as fixed, but I'm
still seeing it.
By "at the opposite end" I meant that bug 12998 was for extra whitespace at
the beginning of the body element and this is extra whitespace at the end.
Bug 12998 is fixed, and this one isn't.
(Reporter)

Comment 5

18 years ago
This one is for whitespace at both ends (see my second comment to the bug
report); and as of Friday, I was still seeing whitespace at both ends being
inserted in the wrong place.
OK... but at the beginning that extra whitespace is outside of body (it was once
inside) whereas at the end it's inside.  It's still not exactly where it was,
though...
"where it was" == "where it was in the document"
(Assignee)

Updated

18 years ago
Assignee: harishd → akkana
(Assignee)

Comment 8

18 years ago
Akkana, looks like there is nothing much that could done on the parser end.

Giving the bug back to you.
IMO, this should be fixed in the parser, just like bug 12998 was.  It's a bug in
conformance with the W3C DOM Level 1 spec.
(Reporter)

Updated

18 years ago
Assignee: akkana → harishd
(Reporter)

Comment 10

18 years ago
If the parser inserts newline nodes in the wrong place in the DOM tree, there's
absolutely nothing the output system can do to distinguish these nodes from
nodes which really were in the original source.
(Reporter)

Updated

18 years ago
Assignee: harishd → rickg
(Reporter)

Comment 11

18 years ago
Rick and I discussed this at some length.  He says that the whitespace at the
end of the document (after the /body and which aren't associated with any other
text or markup besides /html) should be trivial to fix.  For the whitespace
inside the head, at least some of it should also be easy to leave in place
instead of coalescing it into one text node between the head and the body; he's
going to look into that.
(Reporter)

Comment 12

18 years ago
It turns out that this also happens for tables: all newlines occurring inside
table nodes are coalesced into a couple of text nodes outside the table
boundaries.
(Assignee)

Updated

18 years ago
Assignee: rickg → harishd
(Assignee)

Comment 13

18 years ago
stealing!!
(Assignee)

Comment 14

18 years ago
Fixed by updating CNavDTD.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 15

17 years ago
updated qa contact.
QA Contact: janc → bsharma

Comment 16

17 years ago
Verified on:
build: 2001-04-02-09-Mtrunk
platform: WinNT

Marking it verified as per the developer comments.

Do not know how I can view the content tree using release builds?
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.