Closed Bug 48376 Opened 24 years ago Closed 20 years ago

[FIXr]all inline element end tags (e.g. </code>, </tt>) in <dl> eats up whitespace after it

Categories

(Core :: DOM: HTML Parser, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8alpha1

People

(Reporter: larry, Assigned: bzbarsky)

References

Details

(Keywords: testcase)

Attachments

(4 files, 2 obsolete files)

I am using Mozilla M17 for Win32 with TalkBack (build ID 2000080712).

Create a test HTML file with the following contents:

----------------------------------------

<html>
<head>
<title>Test-o-roonie</title>
</head>

<body>

<dl>
<dt>
list 1
<dd>
text

<dl>
<dt>
list 1.a
<dd>
text

</dl>

Hey, <code>lookit</code> the lack of whitespace.

</dl>

</body>
</html>

----------------------------------------

Note that there is a space after the word "lookit", but Mozilla doesn't
render one.  If you add a <dd> before the word "Hey," the space is
correctly rendered.

No one would lay out a page like this (except on accident...), but perhaps
it will lead to discovery of more serious bugs.
Reproduced on Linux 2000-08-10-08.  The problem only occurs with the
Transitional DTD, or an unspecified DTD.  With Strict DTD specified, the problem
does not occur.

The testcase is attached for convenience.
Status: UNCONFIRMED → NEW
Component: Layout → Parser
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Attached file Testcase
Default reassignment.
Assignee: clayton → rickg
QA Contact: petersen → janc
Actually, it only occurs with the quirks/compatability dtd.

I will attach a better testcase which shows that what is actually happening is
that we are closing the <DD> element upon finding a DL element. But DL is legal
inside DD so we cannot do this.
Blocks: html4.01
Severity: trivial → normal
Component: Parser → Layout
QA Contact: janc → petersen
Why is this a beta3 issue?  What % of web pages will get affected by not fixing 
this bug?
Any webpage that nests a DL inside another DL. Not the most common of constructs,
but I'm guessing the fix is just a change to the DTD so it should not be much
of an issue... The strict DTD does this correctly already.
Summary: Minor little rendering bug: Moz drops whitespace after nested <dl> lists and a <code> tag → <dl> nested in <dd> closes parent <dd> (CNavDTD)
I'm inclined to FUTURE this!!!!!
Future seems like a poor choice.  Mozilla's main strength is its leverage of
standards.  HTML authors should be able to rely on predictable and reproduceable
rendering of their markup.  DL could be nested at least all the way back to 2.0.

It would be pretty discouraging to see HTML 2.0/3.2/4.01 compliance marked
future while bugs such as Bug 12761 (JavaScript animation scalability), Bug
24867 (FTP upload), and Bug 38107 (Biff icons?!) are slated for the next branch. 

*** This bug has been marked as a duplicate of 50099 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
Verified dupe.
Status: RESOLVED → VERIFIED
Uh, guys...

I just went and checked, and *none* of the above test cases are rendered
correctly with a fresh build (0.95+, build 2001111008).  Not even the third
one, which purports to "work fine".

This bug is marked as a dupe of 50099, and 50099 is marked as a duplicate
of 57634, and 57634 is marked as fixed.  If that's really the case, then why
am I still seeing the behavior?
I don't know the proper procedures for this stuff, so if I'm doing the wrong
thing please set me straight.  But I just downloaded 0.96 (Win32, on Win2k,
talkback build) and all three testcases for this bug display the problem (even
the "works fine" testcase).  The problem isn't the indention of the final line
of text; it's the magically disappearing whitespace between words on the final
line--between "lookit" and "the" in the first testcase, and between "6" and "7"
in the second and third testcases.

I think part of the problem is that the "summary" description is incorrect; it
doesn't describe the bug I'm reporting.  The problem is Mozilla dropping a
little whitespace.

(I am still academically interested in the problem described in the summary. 
I'd always expected that a nested <dl></dl> inside a <dd> wouldn't close the
parent <dd>.  However, I've gotten used to every browser on the planet behaving
this way, so I just throw in an extra <dd> and be done with it.)
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Attached file minimal testcase
ok seems like Jeffrey Baker got this bug confused with another bug and everyone
fell for it, reporter next time please correct us earlier.

This is caused by moz eating up the whitespace after </code> when it is in a
<dl>, I think this might be affecting other tags as well.
Attachment #12697 - Attachment is obsolete: true
Attachment #12698 - Attachment is obsolete: true
Summary: <dl> nested in <dd> closes parent <dd> (CNavDTD) → </code> (all end tags?) in <dl> eats up whitespace after it.
->default
Assignee: rickg → harishd
Severity: normal → minor
Status: REOPENED → NEW
Component: Layout → Parser
QA Contact: petersen → moied
Target Milestone: --- → mozilla1.0.1
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug, or if it blocks your work in some way
-- please attach your concern to the bug for reconsideration. 

Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → Future
*** Bug 116253 has been marked as a duplicate of this bug. ***
Summary: </code> (all end tags?) in <dl> eats up whitespace after it. → all inline element end tags (e.g. </code>, </tt>) in <dl> eats up whitespace after it
The white space is stripped after inline elements inside a FIELDSET element but
not after inline elements inside a P element.
*** Bug 218249 has been marked as a duplicate of this bug. ***
OK, the original bug here was caused by a bug in our DL parsing.  Jeffrey's
comments were right on the money there.  That parsing bug led to a <dl> having
children that were not <dt> or <dd> (which is exactly what basic's testcase
achieves by creative use of invalid HTML).

Now in nsElementTable.cpp <dl> is marked as a tag which is allowed to discard
all direct child whitespace that's not part of a text run.  Which is what it
does in this case (discards the whitespace at the beginning of text).

I'm not completely sure why this flag is set on <dl>, to be truthful.  Does
anyone know whether there's a way to reach Harish?
No help from CVS logs, I take it?
Ian, you're a funny man.  The CVS log entry for the checkin that added this code
is, in its entirety:

  3.15 <rickg@netscape.com> 1999-04-04 23:55
  major rev to parsing engine

So I suppose Harish wouldn't really have any better idea than any of us.  I
think rickg was just confused in this instance (or rather that rickg was
assuming that somehow authors would not write HTML with bogus crap in <dl>. 
Note that the DTD does not enforce the fact that the only allowed kids of <dl>
are <dd> and <dt>; probably because in the wild people do stick other shit in
there).
Attached patch FixSplinter Review
This should really have no ill side-effects.
Attachment #145376 - Flags: superreview?(hjtoi-bugzilla)
Attachment #145376 - Flags: review?(choess)
*** Bug 239518 has been marked as a duplicate of this bug. ***
Comment on attachment 145376 [details] [diff] [review]
Fix

I find it hard to see what use kOmitWS could be for any tag, but let's remove
it here and for fieldset and let things shake out for a little while just in
case.
Attachment #145376 - Flags: review?(choess) → review+
Taking.
Assignee: harishd → bzbarsky
Status: ASSIGNED → NEW
Depends on: 236589
Priority: P3 → P1
Summary: all inline element end tags (e.g. </code>, </tt>) in <dl> eats up whitespace after it → [FIX]all inline element end tags (e.g. </code>, </tt>) in <dl> eats up whitespace after it
Target Milestone: Future → mozilla1.8alpha
Depends on: 238989
No longer depends on: 236589
Attachment #145376 - Flags: superreview?(hjtoi-bugzilla) → superreview?(peterv)
Comment on attachment 145376 [details] [diff] [review]
Fix

What choess said :-).
Attachment #145376 - Flags: superreview?(peterv) → superreview+
Comment on attachment 145376 [details] [diff] [review]
Fix

More of the same safe parser goodness as fieldset.
Attachment #145376 - Flags: approval1.7?
Summary: [FIX]all inline element end tags (e.g. </code>, </tt>) in <dl> eats up whitespace after it → [FIXr]all inline element end tags (e.g. </code>, </tt>) in <dl> eats up whitespace after it
Comment on attachment 145376 [details] [diff] [review]
Fix

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #145376 - Flags: approval1.7? → approval1.7+
Checked in for 1.7.
Status: NEW → RESOLVED
Closed: 24 years ago20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: