Closed Bug 234612 Opened 22 years ago Closed 16 years ago

</small> inserted into HTML stream

Categories

(Core :: DOM: HTML Parser, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: davidmaxwaterman, Unassigned)

Details

(Whiteboard: [fixed by the HTML5 parser])

Attachments

(1 file)

User-Agent: Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040214 I have a php file that has this code : " <?php $file = "jingmei_students.ldif"; print '<?xml version="1.0" encoding="iso-8859-1"?>'; ?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-US"><head><title>Student Phone List</title> </head><body> <small> <table border="1" width="100%"> <caption>Student Phone List</caption> <tr> <th>Name</th><th>Room</th><th>Phone</th><th>Email</th> </tr> " etc When I access this file using Mozilla (and only Mozilla, as far as I have tested [Safari and IE tested]), it occasionally seems that it inserts a '</small>' into the file, so when I save the page ('view html' doesn't show the extra '</small>') and view it in an editor, it shows : " <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US"><head><title>Student Phone List</title></head> <body> <small> </small><table border="1" width="100%"> <caption>Student Phone List</caption> <tbody><tr> <th>Name</th><th>Room</th><th>Phone</th><th>Email</th> </tr> " etc notice the '</small>' before the table tag. This causes the text in the following table to sometimes be normal sized, and sometimes be small. I realise there is a fair few pieces of s/w that the html goes through before it gets to mozilla, but I am unsure how to determine if it happens before getting to mozilla. If you can tell me, I will gladly run tests. Reproducible: Sometimes Steps to Reproduce: 1.view the php page in mozilla 2. 3. Actual Results: sometimes the text is small, sometimes it is normal size Expected Results: should always be small
If you get the output of the php (eg with wget) and view that, does the problem appear? Note that <table> is not allowed inside <small> in HTML.
> If you get the output of the php (eg with wget) and > view that, does the problem > appear? It does not seem to. I tried running wget 100 times in a loop and none of the output files showed the problem. > > Note that <table> is not allowed inside <small> in > HTML. Hmm. OK (though I'm not entirely sure why since it would seem to make perfect sense to me). Can I put <small> inside <table>, or is there some other correct way of making the text small?
So this only happens when the file is gotten from the server? Does the DOM look the same in both working and non-working cases in DOM inspector? If you could post a URL where the bug could be reproduced, that would be very helpful. As for HTML, you can put <small> inside a <td>. Or you can just use style="font-size: smaller" on the table.
> So this only happens when the file is gotten from > the server? Sorry, I'm not sure I understand what you are asking. The problem is only apparent when I access the file using Mozilla. I have tried using Safari and Explorer, and wget too, but it seems to work fine with those clients. > Does the DOM look > the same in both working and non-working cases in > DOM inspector? OK, I've found the DOM Inspector now :) It looks differently in non-working and working cases : (working) : http://reality.sgiweb.org/maxw/tmp/mozilla/mozilla_234612-small.jpg (non-working) : http://reality.sgiweb.org/maxw/tmp/mozilla/mozilla_234612-large.jpg I notice that the DOM does reflect the way it is displayed, as does the content when the page is saved to a file, but the 'view page source' always looks correct (ie no extra '</small>' before the '<table>' tag). > If you could post a URL where the bug could be > reproduced, that would be very > helpful. Sorry, but it's not on the web, and it contains personal information...also, I tried change the content to non-confidential, but that changes the behaviour :( > > As for HTML, you can put <small> inside a <td>. Hmm. OK, thanks. Curious why it is not allowed to have it on the outside, but anyway...good to know. > > Or you can just use style="font-size: smaller" on > the table. Hmm. This is better, I think I'll do this. Thanks. >
Hmm.. sounds like the parsing depends on where the packet boundaries fall or something wacky....
> Hmm.. sounds like the parsing depends on where the > packet boundaries fall or > something wacky.... OK. Am I right in thinking there is something to 'fix' here, even thought the HTML isn't strictly conformant?
Yes. Which is why it would be great if we had a way to reproduce this....
OK, I'll work on seeing if I can make it do it with dummy data.
well, I tried to make a test case, and have come up with this : http://reality.sgiweb.org/maxw/tmp/mozilla/bug.php it actually seems to consistently produce only the problem case, rather than the 'correct' case. I notice that, when I load the page in safari, explorer and mozilla, and then save the page to a file (safari.html, explorer.html, mozilla.html), that only mozilla.html has the '</small>'. Hope this helps.
Interesting. For me that shows the "correct" case... I'll try to see whether I can find what makes it break.
"correct"? Are we using the same definition for 'correct'? "Correct" == smaller text "incorrect" == larger text
Yep. My definition is actually "correct" == "table insied <small> in the DOM". Which leads to smaller text, of course.
For reference, bug 117441, bug 62782, bug 137628, and bug 154304 all seem to be or have been connected with packet boundaries as a cause of parsing variability.
Confirming based on comment 7. A reduced testcase would be nice though...
Status: UNCONFIRMED → NEW
Ever confirmed: true
I believe this is fixed by bug 487949.
Assignee: parser → nobody
QA Contact: parser
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: