wrong layout for empty tables

VERIFIED FIXED

Status

()

Core
HTML: Parser
P2
normal
VERIFIED FIXED
20 years ago
11 years ago

People

(Reporter: buster, Assigned: harishd)

Tracking

({testcase})

Trunk
x86
Windows NT
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Table should be a single pixel line all across the horizontal width of the window)

Attachments

(1 attachment)

(Reporter)

Description

20 years ago
<html> <body>
 1
<table border=1 width="100%">
<tr><td></td></tr>
</table>
2
<br>
3
<table border=1 width="100%">
<tr></tr>
</table>
4
</body> </html>
(Reporter)

Updated

20 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

20 years ago
Assignee: buster → rickg
Status: ASSIGNED → NEW
Component: HTMLTables → Parser
(Reporter)

Comment 1

20 years ago
The table code is doing the right thing with the content that it is being
given.  The "problem" is with the parser (or content sink?)
I think what raptor does is compliant with the HTML 4.0 DTD.  Perhaps this
should be a "quirk"?  The quirk behavior would be to throw away any table that
didn't have at least one cell.  Quite a bit of experimenting would be necessary
to determine exactly what cases would need to be addressed.

Updated

20 years ago
Assignee: rickg → buster

Comment 2

20 years ago
hang on there bucko. This is a not a parser bug. You should address this issue
with Kipp.
(Reporter)

Updated

20 years ago
Status: NEW → ASSIGNED
(Reporter)

Updated

20 years ago
Assignee: buster → karnaze
Status: ASSIGNED → NEW

Updated

20 years ago
Status: NEW → ASSIGNED

Comment 3

20 years ago
Setting all current Open/Normal to M4.

Comment 4

19 years ago
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Updated

19 years ago
Target Milestone: M4 → M6

Comment 5

19 years ago
moving to M6

Comment 6

19 years ago
Moving to M8.

Comment 7

19 years ago
This behavior looks nearly correct to me, as since a table is there, but there
is nothing in it, no </td>'s and the only <tr> is empty, with only a border, so
I think showing a 1 pixel dot like that is technically correct, but since the
table width was set at 100%, should the pixel thing not be a line across the
screen? Since there is only one row, but the table has no depth, I do think that
a 1 pixel wide line would be right to draw with that code. This may be realted
to bug#5797 , which is causing a tables width not to be displayed properly. What
it does is that it only makes it as wide as is needed to fit text, pictures etc.
But since this is empty no room is needed and it only dispalyes the dot to
satisfy the border=1 atribute?

Comment 8

19 years ago
Moving to M9.

Updated

19 years ago
Whiteboard: [MAKINGTEST] jonesev@home.com July 28

Updated

19 years ago
Whiteboard: [MAKINGTEST] jonesev@home.com July 28 → [TESTCASE] Table should be a single pixel line all across the horizontal width of the window

Comment 9

19 years ago
Created attachment 1026 [details]
This is the test described in this bug

Comment 10

19 years ago
I attached the HTML file mentioned by buster@netscape.com and added one
additional bit:

<br>
5
<table border=1 width="100%">
<tr><td>&nbsp;</td></tr>
</table>
6

As of the July 26 Linux build, the top table is close to correct (should be a
single pixel line, but instead it has a space in there). The middle box is
incorrect (should it be a line or not there at all because it is an incorrect
table?) and the bottom box is close (It is correct but with a thicker than one
pixel border. The same behavior is evident in the Win32 version.

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 11

19 years ago
The layout is now very close to Nav4.x except that the 3 and 4 appear on
different lines, which is what IE5 does. The first table can be made less tall
by setting cellspacing and cellpadding to 0. If someone can find in any spec
support for the notion that the 1st table should be a single line, I'll make it
work that way in Standard mode.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 12

19 years ago
verified 1999080508

Updated

19 years ago
Status: VERIFIED → REOPENED
The layout is wrong again, using 1999102208 build.
Reopening.

Updated

19 years ago
Assignee: karnaze → harishd
Status: REOPENED → NEW

Comment 14

19 years ago
Harish, a content dump reveals that the lines with "1" and "2" are coming before
the 1st table which is a regression.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 15

19 years ago
Aware of the problem and I've the fix in hand.
(Assignee)

Updated

19 years ago
Resolution: FIXED → ---

Updated

19 years ago
Target Milestone: M9
(Assignee)

Comment 16

19 years ago
*** Bug 17113 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 17

19 years ago
Rectified the problem in CNavDTD::AddLeaf(). Marking FIXED.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 18

19 years ago
verified again

Updated

11 years ago
Keywords: testcase
Whiteboard: [TESTCASE] Table should be a single pixel line all across the horizontal width of the window → Table should be a single pixel line all across the horizontal width of the window
You need to log in before you can comment on or make changes to this bug.