Closed
Bug 234612
Opened 22 years ago
Closed 16 years ago
</small> inserted into HTML stream
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: davidmaxwaterman, Unassigned)
Details
(Whiteboard: [fixed by the HTML5 parser])
Attachments
(1 file)
|
218 bytes,
text/html
|
Details |
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
Comment 1•22 years ago
|
||
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.
| Reporter | ||
Comment 2•22 years ago
|
||
> 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?
Comment 3•22 years ago
|
||
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.
| Reporter | ||
Comment 4•22 years ago
|
||
> 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.
>
Comment 5•22 years ago
|
||
Hmm.. sounds like the parsing depends on where the packet boundaries fall or
something wacky....
| Reporter | ||
Comment 6•22 years ago
|
||
> 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?
Comment 7•22 years ago
|
||
Yes. Which is why it would be great if we had a way to reproduce this....
| Reporter | ||
Comment 8•22 years ago
|
||
OK, I'll work on seeing if I can make it do it with dummy data.
| Reporter | ||
Comment 9•22 years ago
|
||
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.
Comment 10•22 years ago
|
||
Interesting. For me that shows the "correct" case... I'll try to see whether I
can find what makes it break.
| Reporter | ||
Comment 11•22 years ago
|
||
"correct"? Are we using the same definition for 'correct'?
"Correct" == smaller text
"incorrect" == larger text
Comment 12•22 years ago
|
||
Yep. My definition is actually "correct" == "table insied <small> in the DOM".
Which leads to smaller text, of course.
Comment 13•22 years ago
|
||
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.
Comment 14•21 years ago
|
||
Confirming based on comment 7. A reduced testcase would be nice though...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 15•16 years ago
|
||
Comment 16•16 years ago
|
||
I believe this is fixed by bug 487949.
Updated•16 years ago
|
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.
Description
•