Closed
Bug 8873
Opened 25 years ago
Closed 25 years ago
Some table cells fail to show background colour
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: run2000, Assigned: karnaze)
References
()
Details
(Keywords: testcase, Whiteboard: [TESTCASE])
Attachments
(2 files)
Occurs on M7 release, under NT 4 Workstation.
At the top of the Bluemountain page, there is a blue navigation bar consisting
of two tabs. Underneath this should be a thin yellow line. On M7 this line does
not appear. (Ignore the blue line that appears instead -- this is a
manifestation of bug 5900.)
Will attach test case to simplify the problem. The test case only shows the
problem when both:
* the table cell contains the "nowrap" attribute
* the spacer image inside the cell is right aligned (floated)
This code behaves correctly on IE5 and Opera 3.6
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Summary: Funny interaction with Nowrapped table cell and floating image → Some table cells fail to show background colour
Reporter | ||
Comment 3•25 years ago
|
||
Created a new test case, this time relating to the use of spacer elements
within an HTML table. The code snippet is modified from bug 3312.
The test consists of three tables. Any browser that supports both table height and
spacer elements should render the three tables identically.
The first table shows the background colour appearing for the entire second row,
but for neither the first nor third rows. Both first and third rows have been drawn
with the correct cell height. The third row has not drawn its border separating it
from the second row.
The second table shows the table normally, with all cells having their background
painted correctly.
The third table paints the background colour on the first cell of the first and third
rows, and for the entire second row. The only difference between the rows here is
the text that appears in the second row.
The problem appears to be that the code handling the painting of cell backgrounds
can't tell correctly when the cells in question have been collapsed.
Changing the summary field to reflect the new test case.
Updated•25 years ago
|
Whiteboard: [TESTCASE]
Comment 4•25 years ago
|
||
[TESTCASE]
The two attachements appear to be adequate test cases.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M11
Reporter | ||
Comment 5•25 years ago
|
||
The first testcase now works ok.
See also bug 10036 for similar issues with other elements, such as <br>.
Assignee | ||
Comment 6•25 years ago
|
||
Moving to M13.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M14
Assignee | ||
Comment 7•25 years ago
|
||
mass move to m14.
Comment 8•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Assignee | ||
Comment 9•25 years ago
|
||
The url and attachements look ok compared to IE. The 2nd attachement does give a
different width to the cells with images which can't be found. ChrisD if you
think this should keep the bug open, please reassign to Kipp's bug list.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Target Milestone: M14
Comment 10•25 years ago
|
||
5.0 is rendering the 3 tables identically in 2/9 build. Verifying WORKSFORME.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•