Note: There are a few cases of duplicates in user autocompletion which are being worked on.

1px double borders not painting at all with border-collapse:collapse

VERIFIED FIXED in mozilla6

Status

()

Core
Layout: Tables
P2
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Paul Grosso, Assigned: bz)

Tracking

unspecified
mozilla6
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Firefox 4.0.1 ("up to date" as of 2011 May 2)

Using the collapsing border model in tables, I am not always getting the border conflict resolution behavior I expect.  The page at http://paulgrosso.name/firefox/tablerules.htm is self-documenting and contains more details.

Reproducible: Always


Actual Results:  
See http://paulgrosso.name/firefox/tablerules.htm

Expected Results:  
See http://paulgrosso.name/firefox/tablerules.htm
(Assignee)

Comment 1

6 years ago
So the issue here is that in the collapsed border model a 1px wide "double" border is not showing up, right?  That probably has to do with the fact that painting a 1.33px wide "double" (which really needs at least 3px to show up) border  _exactly_ on top of a pixel boundary doesn't work very well, not with border conflict resolution...  In the separated border case, the drawing code is different, and the border is positioned on top of a pixel, not on top of a boundary, so things work out better.

We should probably just treat "double" borders thinner than 3px as solid in the table BC drawing code.
(Reporter)

Comment 2

6 years ago
Perhaps that is the crux of the issue, because when I made its style solid (or dashed, etc.), it does show.  In which case it isn't a conflict resolution issue.  I was misled when the separated border case showed the 1pt double rule properly (I was not aware that the drawing code is different in that case).  Thanks for the response.
(Reporter)

Comment 3

6 years ago
But now compare http://paulgrosso.name/firefox/ff4-border-collapse.htm and http://paulgrosso.name/firefox/ff4-border-collapse2.htm which are identical except the second has an extra global CSS rule setting border style to none for the top and left rules on hd and th.  In the first case, the top rules for the third and fourth table are black, not red as I would have expected.  It looks like the default th, td border style is 1.5pt, black, solid, so that the default is taking precedence over a specified solid rules unless what's specified is at least 1.5pt wide.
(Assignee)

Comment 4

6 years ago
> It looks like the default th, td border style is 1.5pt, black, solid

The default styles if you specify rules="none" are the ones in bug 648531 comment 2.  Those include "border-width: thin", which should be 1px wide.  The border-collapse code converts all widths into integer pixel widths before doing conflict resolution (which is arguably a bug) and it looks like it does so by truncating, not rounding (another bug).  1pt is 1.333333px.  So 2px is 1.5pt, and hence any value smaller than 1.5pt will be truncated to 1px.  And then the thin border is the same width and it wins because of rule 4 in border conflict resolution.

Worth checking whether the bugs about comparing after conversion to integer pixels and the fact that the conversion truncates instead of rounding are filed; if not, we should get them on file.  But we should definitely fix the painting issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Table border conflict resolution is not working as I expect → Thin 1px double borders not painting at all with border-collapse:collapse
(Assignee)

Comment 5

6 years ago
Created attachment 529542 [details]
Small testcase for that problem
(Assignee)

Comment 6

6 years ago
Here's the problem in nsCSSRendering::DrawTableBorderSegment :

  case NS_STYLE_BORDER_STYLE_DOUBLE:
    if ((aBorder.width > 2) && (aBorder.height > 2)) {

Except aBorder is in app units (so 1px is 60, not 1).

Fix coming up once I figure out when this broke.
Assignee: nobody → bzbarsky
(Assignee)

Comment 7

6 years ago
Looks like this has been broken at least back to Firefox 3.0.  Gotta love lack of tests...
(Assignee)

Comment 8

6 years ago
And broken in Firefox 2 as well.  I'm going to stop worrying about this!
(Assignee)

Comment 9

6 years ago
This might just be broken back to bug 41262 or earlier.  Anyway, patch coming up.
(Assignee)

Comment 10

6 years ago
Created attachment 529563 [details] [diff] [review]
Fix drawing of thin 'border-style: double' border-collapsed borders.
Attachment #529563 - Flags: review?(roc)
(Assignee)

Updated

6 years ago
Priority: -- → P2
Summary: Thin 1px double borders not painting at all with border-collapse:collapse → 1px double borders not painting at all with border-collapse:collapse
Whiteboard: [need review]

Updated

6 years ago
Duplicate of this bug: 381564
(Assignee)

Comment 12

6 years ago
Oops.  I should have searched for existing bugs.  :(
Comment on attachment 529563 [details] [diff] [review]
Fix drawing of thin 'border-style: double' border-collapsed borders.

Review of attachment 529563 [details] [diff] [review]:
Attachment #529563 - Flags: review?(roc) → review+
(Assignee)

Updated

6 years ago
Whiteboard: [need review] → [need landing]
(Assignee)

Comment 14

6 years ago
http://hg.mozilla.org/mozilla-central/rev/798050382d9a
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla6
Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0

Verified issue on Windows XP, Windows 7, Mac OS X 10.6 and Ubuntu using the page from Comment 0 (http://paulgrosso.name/firefox/tablerules.htm) and the test case attached in Comment 5.

Setting resolution to VERIFIED FIXED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.