172649 - paragraph style only overrides font tag when loading from cache

Status: RESOLVED WONTFIX

(Core :: DOM: HTML Parser, defect)

Description

[kaldari]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; rv:1.0.1) Gecko/20021003
Build Identifier: 

At http://www.tnrc.net/styletest.html, the CSS style defined for paragraphs
isn't overriding the surrounding font tag until you reload the page. This is
reproducable about 75% of the time for me (you'll have to clear your disk cache
to reproduce it after the first time). I thought it might be a Gecko bug at
first, but I can't reproduce it in Mozilla 1.1 (8/26 Gecko build).
Interestingly, if I get rid of any of the paragraphs on the page, I can no
longer reproduce the bug. Maybe there's a memory threshhold to it. Here's
another page you can usually reproduce the bug on, this time with a linked
stylesheet: http://www.tnrc.net/about.html (the body font should be smaller when
you reload). I will attach screenshots momentarily.

I'm using Chimera 2002100304 on 10.2.1.

Reproducible: Sometimes

Steps to Reproduce:
1. Go to http://www.tnrc.net/styletest.html and the paragraphs will probably be
using Times size 3 (what the font tag surrounding the paragraphs says)
2. Hit the reload button, and the paragraphs will magically change to Verdana
11px (what the CSS definition for paragraphs says).
3. To reproduce again, clear your cache and start over.

Actual Results:  
Paragraph style changes to what the CSS definition says once you reload the page.

Expected Results:  
Paragraphs should render using the CSS definition to start with.

Comment 1

[kaldari]

Attachment: before and after reload comparison

Notice only the paragraphs are rendered incorrectly, the unordered list is
fine.

Comment 2

[Greg K.]

WorksForMe using Chimera/2002100304 on 10.1.5.

Comment 3

[kaldari]

WorksForMe from home using the identical build on the identitcal OS. Maybe its
some kind of profile bug. I'll try doing a clean install on my work machine
Monday and see if it's still reproducable.

Comment 4

[kaldari]

I'm having a hard time reproducing this bug now on my original testcase page
(using build 2002101004), but it still seems pretty consistant on the following
page:
http://www.tnrc.net/how_to_organize.html
Note that the bug is affecting definition lists here rather than paragraphs.

I still have yet to test out a totally clean install, but hopefully I'll get a
chance today.

Bug 173773 may be a dupe of this one.

Comment 5

[kaldari]

I did a totally clean install and the bug is still consistantly reproducable for
me from my work machine (using 2002101404 on 10.2.1).

Comment 6

[kaldari]

Also tried using a different profile, but the bug is still present.

Comment 7

[Greg K.]

[e-mail], can you reproduce this under another OS X user account on
the same machine?

Comment 8

[kaldari]

Yes, but only on the same machine.

Comment 9

[Simon Fraser [no longer active]]

I can repro this by shift-reloading, and it also happens in a trunk Mozilla
build. Maybe it's caused by a race in stylesheet loading?

A reduced testcase would be useful.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

My guess would be that the Parser is doing different things depending on whether
something arrives in one packet or split between two.  (There are some other
bugs like that in the Parser component.)  That's just a guess.  I couldn't
reproduce on Linux 1.2.1.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Compare:

http://dbaron.org/mozilla/tests/172649.cgi?delay=0
http://dbaron.org/mozilla/tests/172649.cgi?delay=5

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Actually, a better comparison is 

http://dbaron.org/mozilla/tests/172649.cgi?delay=5
http://www.tnrc.net/styletest.html

When the processing is split, the Parser is splitting up the FONT ("residual
style") and putting it inside the P rather than putting the P inside the font. 
(Have a look in DOM Inspector.)

->Browser/Parser

Comment 13

[Simon Fraser [no longer active]]

Kin mentioned a bug like this

Comment 14

[kaldari]

Looks like this bug is still present in Firefox 0.8. Since harishd is gone(?)
maybe this bug should be reassigned.

Comment 15

[Blake Kaplan (:mrbkap) (inactive)]

I'm going to mark this WONTFIX. Unfortunately, this is the result of a couple of
design decisions. Comment 10 is right on the money here. What the parser tries
to do when it encounters invalid HTML (such as <font><p>) is to determine
whether or not the incoming HTML is "well formed" (i.e., whether all of the
start and end tags line up). If it is well formed, then it allows the invalid
HTML (it allows the <font> to contain the <p>). If it cannot determine if the
tags are well formed or not, then it uses "residual style handling" which means
that it closes the <font> and reopens it inside the <p>, causing the styles from
the <font> to outweigh the styles from the <p>. In this case, whether or not it
can determine if the document is wellformed is based on the packet boundaries.