Closed Bug 42180 Opened 25 years ago Closed 25 years ago

<pre> element treated as inline element -- should be block

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: waterson, Assigned: rickg)

References

(
URL
)

Details

(Keywords: html4, regression, Whiteboard: [nsbeta2+] was: in DEBUG builds, <pre> text is displayed with tags in strict mode)

Attachments

(2 files)

minimized test case
(deleted), text/html
Details
revised testcase
(deleted), text/html
Details
The ingredients seem to be <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> (That means "strict mode", right?), and some <pre>-formatted text with embedded tags; e.g., <pre><a name="1">1</a></pre> Expected result: see a blue, underlined "1". Actual result: <a>1</a> I'll attach a minimal test case.
Attached file minimized test case (deleted) —
The doctype literally means transitional, which is only barely different from strict. (I'll give you the gory details if you really care.) I'll take a look.
Yup -- pre is definitely broken. I'll dig deeper.
Marking nsbeta2 because: 1) <pre> tags are commonly used; 2) it's a trivial fix (in hand) and 3) RickG is going on sabbatical, so it's now or never.
Status: NEW → ASSIGNED
Keywords: nsbeta2
Fix in hand
Whiteboard: fix in hand
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: fix in hand → [nsbeta2+]fix in hand
Fixed by treating the <pre> element like the inline that it is.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Minor problem though Rick... <pre> isn't an inline element! This 'fix' has broken most of my test pages, since <pre> content is now being dropped if it is child of <body>, which is perfectly legal. Reopening. If you need a specific test case, give me a shout.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: in DEBUG builds, <pre> text is displayed with tags in strict mode → <pre> element treated as inline element -- should be block
Whiteboard: [nsbeta2+]fix in hand → [nsbeta2+] was: in DEBUG builds, <pre> text is displayed with tags in strict mode
Blocks: html4.01
Keywords: regression
*** Bug 42698 has been marked as a duplicate of this bug. ***
From bug 42698 by David: DESCRIPTION: The [following] URL has two PRE elements that aren't showing up. Neither they nor any of their contents are in the content model. STEPS TO REPRODUCE: * load http://www.people.fas.harvard.edu/~dbaron/www/httpreq ACTUAL RESULTS: * No HTTP headers listed. EXPECTED RESULTS: * lots of HTTP headers listed DOES NOT WORK CORRECTLY ON: * Win98 mozilla 2000-06-15-08-M17 ADDITIONAL INFORMATION: This is a major regression, and thus nominating nsbeta2.
Keywords: 4xp, html4
Ack! Yes, of course, what was I thinking. I was attempting to get the right answer (which is to allow inline elements in pre) but went too far. Fixed (again) in my tree.
Ack! Yes, of course, what was I thinking. I was attempting to get the right answer (which is to allow inline elements in pre) but went too far. Fixed (again) in my tree.
Status: REOPENED → ASSIGNED
Landed fix. Please retest.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Reopening I get a 1 with no <a> tags, but the 1 is not a link (no underline) 2000-07-12-11-M17 : Linux 2000-07-12-09-M17 : WinNT & Win98 2000-07-12-13-M17 : Mac
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Not sure, if this is important, but the first assumption is wrong. With the current source the DOCTYPE will NavQuirks rendering. This happens because the SystemID is missing. Use the following DOCTYPE to get STANDARD/TRANSITIONAL mode: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> and this one to turn STANDARD/STRICT on: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> For further details please look into nsParser.cpp. However all modes render equally - a 1 without an underline.
Attached file revised testcase (deleted) —
Chris's original description of expected behavior was wrong - there should be no underline in his testcase. I attached a revised testcase with the name changed to href, so there should be an underline. Marking fixed again.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Reopening to resolve correctly.
Status: RESOLVED → REOPENED
Resolving again
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
With 4.x now, reopening...
Status: RESOLVED → REOPENED
And resolving as ***FIXED***.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
looks good to me Marking verified. Verified 2000-07-17-13-M17 : Linux 2000-07-17-09-M17 : WinNT & Win98 2000-07-13-08-M17 : Mac
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: