215714 - <pre> gets confused if preceded by font setting plus <p>

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[Craig]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5a) Gecko/20030718

Wrapping a <pre> in a <font> setting, plus having a <p> immediately before the
<pre>, stops the <pre> working properly. Either the font setting or the <p> on
its own doesn't cause this behaviour.

Reproducible: Always

Steps to Reproduce:
1. Put this code on a page:
<font face="Verdana">
This is some text in Verdana.<p>
<pre>
|       | this vertical bar should be
|-----==| directly above this one, but it's not
</pre></font>
<font face="Verdana">
This is some text in Verdana.
<pre>
|       | this vertical bar really is
|-----==| directly above this one!
</pre></font>


Actual Results:  
It's self-documenting: First set of vertical bars don't line up, even though
second set do.


Expected Results:  
Been consistent.

Comment 1

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 2

[Mats Palmgren (inactive)]

WFM, 2003-08-08-22 trunk Linux

Comment 3

[Craig]

Oops. Even weirder that I thought.

That testcase gives me both sets of bars failing to line up. However, if a <p>
is inserted before the first <font> tag, then it works as I said.

Comment 4

[Mats Palmgren (inactive)]

Attachment: Testcase #2 (with <p> before first <font>)

Still WFM on Linux (in both Quirks and Standards mode BTW)

Comment 5

[Mats Palmgren (inactive)]

Confirming bug, 2003-08-10-04 trunk Win98.  DOM Inspector shows:
<FONT face="Verdana">
<P>
<PRE>
    <FONT face="Verdana">
...

-> Parser

Comment 6

[Mats Palmgren (inactive)]

Bug also occurs in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1b) Gecko/20020804

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase #3 (same as #2 but using Times font)

Bug also occurs on Linux, it didn't show up with the previous testcases because

my Linux box don't have the Verdana font.  This testcase uses Times instead.

Comment 8

[Craig]

Thanks for checking into it, Mats.
FWIW, also occurs in Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030810.

Comment 9

[Mats Palmgren (inactive)]

*** Bug 215780 has been marked as a duplicate of this bug. ***

Comment 10

[Hermann Schwab]

Bug 215780 is a 4xp bug, as its URL and testcase are working on Netscape 4.79
None of these testcases here is working on Netscape 4.79

tested on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5b) Gecko/20030810
Mozilla: testcase 1 wrong, second <pre> this vertical bar is NOT directly ...
Netscape 4.79: all testcases no bar directly above the other, all bars misaligned.

Comment 11

[Donald J. Axel]

I think <pre> should switch to monospaced font, other browsers do.

Comment 12

[Donald J. Axel]

Attachment: <style> pre {font-family: "Courier New", Courier, monospace;} alters <pre> font away from monospace

Konqueror and "links -g" has it right, so I believe Mozilla to be off-beat
here.
If you remove the <style> sheet pre definition then things change to normal.
I got the problem reading
http://www.anzwers.org/free/universe/nebulae/ic1805.html which is quite
complicated, so I simplified and found the offending line.
Regards/Donald Axel - d-axel.dk.

Comment 13

[Mathew McBride]

This condition is not altered in any way if <font> or a font other than Courier
 is inside the pre. Take this xml dump from for
http://www.atomicmpc.com.au/forums.asp?s=1&c=2&t=4245 example:
<PRE style="font-family: Courier,monospace;">
  <FONT color="#ffffff" size="2" face="Arial">
     <BR/>
[cut]
Bobbles                 2     <BR/>
Bomfunk                 1     <BR/>
bomfunky_1999           1     <BR/>
Bonez                   1     <BR/>
BonezOfOz               1      2     <BR/>
  </FONT>
</PRE>
add style="font-family: Courier, monospace;" to the <font> and it looks like it
should be.

Unfortunately, I don't think we should bother modifying html.css to force
courier, monospace by default. 

Comment 14

[Mathew McBride]

Attachment: Screenshot of M18 rendering it correctly

M18 defaulted to the Courier font and got it right.

Comment 15

[Mathew McBride]

Attachment: Shot comparing M18 - present day

Comment 16

[Allen Pestaluky]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Here's another example of a similar issue:
http://virtualeclipse.ca/ebtabs/bass/eb/battle7_dougertous/

This one is a bit weird: half the time it will show up in Arial (like the rest
of the site), half the time it will be properly monospaced. Refreshing the page
(sometimes multiple times) seems to fix the problem.

Going to the following site and then clicking on the second "Battle #7" link
under "EarthBound" seems to trigger it more often than not:
http://virtualeclipse.ca/ebtabs/

Comment 17

[Blake Kaplan (:mrbkap) (inactive)]

I'm marking this WONTFIX. This is a result of the residual style handling that
the parser does, and there is no way to not do residual style handling in this
case (and form a correct DOM).