Closed
Bug 196133
Opened 22 years ago
Closed 22 years ago
Table borders with border-collapse: collapse rendering incorrectly
Categories
(Core :: Layout: Tables, defect, P3)
Core
Layout: Tables
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: jsbiff, Assigned: bernd_mozilla)
References
()
Details
(Keywords: testcase)
Attachments
(6 files)
(deleted),
text/html
|
Details | |
(deleted),
text/css
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
john
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
(deleted),
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
When Mozilla/NS7 paint this table, the outer borders are rendered with gaps. If
you hit reload, the side borders completely disappear. If you scroll up and down
the page, some of the side borders will get repainted. The table validates as
XHTML 1.0 Strict and as CSS using the W3C Validators (links on bottom of page).
Reproducible: Always
Steps to Reproduce:
1.Load page
2.View table
3.Hit reload button
4.Scroll the page.
Actual Results:
See details above.
Expected Results:
Render complete borders around the entire table consistently.
Reporter | ||
Comment 1•22 years ago
|
||
This is a copy of the page output. We are still doing development on the page
so I thought I'd put up a 'static' copy of the file as an attachment for you
guys to work from.
Reporter | ||
Comment 2•22 years ago
|
||
css file to use with Testcase.html
Comment 3•22 years ago
|
||
Happens on Linux too....
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: DUPEME
Reporter | ||
Comment 4•22 years ago
|
||
Forgot to mention - the bottom border of the table also never seems to render.
Comment 5•22 years ago
|
||
Comment 6•22 years ago
|
||
could be similar to (dup of) bug 159108 ?
No, if the border painting improves only by adding a margin wide enough to
incorporate the border then it is a dupe of bug 159108. Otherwise it is a bug on
its own.
Reporter | ||
Comment 8•22 years ago
|
||
Well, if you look at the original test case (and, I suspect, the "a very reduced
testcase") there *is* a sufficiently wide margin around the table to incorporate
the border, and yet it is still rendering incorrectly. Not to mention, I believe
that bug 159108 has been 'fixed' for a while. Yet this is still rendering
incorrectly. So, I don't believe that this is a dupe of that bug.
Updated•22 years ago
|
Target Milestone: --- → Future
Reporter | ||
Comment 9•22 years ago
|
||
Minor clarification: In the external stylesheet specs.css, I set the table width
to 96%, and I set the left and right margins to be 'auto' so that the table
would center up nicely. That said, on my computer the margins expand out to
about 4-5 times the thickness of the border as a result of being set to 'auto',
so there *should* be sufficient margin. So, again, I don't believe this is a
dupe of the other bug. Sorry for the double-post, I should have checked the
document and included this info in the first post.
Comment 10•22 years ago
|
||
I have been seeing this bug consistently on one website. It doesn't draw the
side borders (left/right) when the page loads. But if you scroll the page up and
down the borders partially show up. I have created a really small testcase to
illustrate the problem.
Comment 11•22 years ago
|
||
If you resize the browser window to be really small so the the vertical
scrollbar shows up and when you scroll the borders will magically appear during
scrolling.
Assignee | ||
Comment 12•22 years ago
|
||
Attachment #121848 -
Flags: superreview?(roc+moz)
Attachment #121848 -
Flags: review?(jkeiser)
Assignee | ||
Comment 13•22 years ago
|
||
Just some hints for the reviewer :-)
Collapsed border are painted via the table frame. (PaintBCBorder) This is not
optimal. But this what we have now. As they are painted by the table frame Chris
optimized them to the limit (one might also say far beyond the limit) by
painting as large as possible segments. So looking
at http://bugzilla.mozilla.org/attachment.cgi?id=120736&action=view it would
paint only two vertical segments and not 2x2. The start of a segment is cached
and only the start of a new segment or the end of the table causes the cached
segment to be painted. Before the proposed patch we did look up the style
information when the segment needed to be painted. But we looked up the current
row or rowgroup and not the row or rowgroup that have been used when the
segment started and provided the ownership for this segment. Easy isnt it :-)
Updated•22 years ago
|
Attachment #121848 -
Flags: review?(jkeiser) → review+
Attachment #121848 -
Flags: superreview?(roc+moz) → superreview+
Comment 15•22 years ago
|
||
is there any progress on this bug? what else is needed for the patch to go in?
Assignee | ||
Comment 16•22 years ago
|
||
A open tree, for me this is not 1.4 worthy(risk vs gain), I can not with full
confidence claim that there is low risk.
Comment 17•22 years ago
|
||
Does patch resolve this testcase?
Assignee | ||
Comment 18•22 years ago
|
||
fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•