Closed Bug 48376 Opened 25 years ago Closed 21 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: 25 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: 25 years ago21 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: