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)

defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: jsbiff, Assigned: bernd_mozilla)

References

()

Details

(Keywords: testcase)

Attachments

(6 files)

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.
Attached file Testcase html (deleted) —
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.
css file to use with Testcase.html
Happens on Linux too....
OS: Windows 2000 → All
Hardware: PC → All
Whiteboard: DUPEME
Forgot to mention - the bottom border of the table also never seems to render.
Attached file a very reduced testcase (deleted) —
could be similar to (dup of) bug 159108 ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Priority: -- → P3
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.
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.
Target Milestone: --- → Future
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.
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.
Attached file My small testcase (deleted) —
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.
Attached patch patch (deleted) — Splinter Review
Attachment #121848 - Flags: superreview?(roc+moz)
Attachment #121848 - Flags: review?(jkeiser)
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 :-)
Attachment #121848 - Flags: review?(jkeiser) → review+
Attachment #121848 - Flags: superreview?(roc+moz) → superreview+
mine
Assignee: table → bernd_mozilla
is there any progress on this bug? what else is needed for the patch to go in?
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.
Does patch resolve this testcase?
fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: