286794 - border-collapse tables cause unnecessary one pixel of overflow (causing scrollbar)

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P1)

Description

[Frank Wein [:mcsmurf]]

To reproduce:
1. Open testcase
2. Observe horizontal scrollbar also none is needed

This bug was caused by Bug 271755.

Comment 1

[Frank Wein [:mcsmurf]]

Attachment: Testcase

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think the solution here is to make the BC table cell code store the full width
of the border and pick the appropriate half when it needs one half or the other.
 While there, I'd also want to convert these values to 16-bit instead of 8-bit.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 288515 has been marked as a duplicate of this bug. ***

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

This patch does a bunch of things (it's not that big, though):
 * converts the BC border widths to 16-bit numbers and coverts the remaining (I
hope) users of PRUint8 or PRUint32 foo : 8 to use the BCPixelSize typedef
 * changes what nsBCTableCellFrame stores to be the entire border width instead
of just the inner half
 * simplifies a bunch of the functions using the BCPropertyData using the
macros in nsTablePainter.h
 * adds a float() cast to clarify the macros in nsTablePainter.h (I don't think
this should change anything, and it's what some of the existing callers were
doing, but not others)
 * adds some comments
 * fixes a few other nits I had in my tree (all minor)

It does *not* convert what the columns and rows store to be the entire border
width, so we still have that inconsistency.  That's a good bit more work, and I
didn't feel the need to do it right now to fix this regression.  (The
BCPropertyData for the table already stored the whole thing, so I've just made
the inconsistency (table, cell) vs. (row, column) instead of (table) vs. (row,
cell, column).	It's probably worth fixing columns and rows at some point too.)

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Oh, it also removes an unused version of SetBorderWidth on nsBCTableCellFrame.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Hrm, still doesn't fix bug 224309.  Maybe a new patch shortly, if I find the
problem...

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

This adds the additional changes needed to make borders wider than 63px
actually work.

Comment 8

[José Jeria]

*** Bug 288576 has been marked as a duplicate of this bug. ***

Comment 9

[Bernd]

Comment on attachment 179669 [details] [diff] [review]
patch

looks good to me

Comment 10

[Bernd]

Comment on attachment 179672 [details] [diff] [review]
patch

this patch is rather the thing that needs review... ;-)

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 179672 [details] [diff] [review]
patch

This is a fix for a regression I caused a few weeks ago.  Not a tiny patch, but
relatively straightforward.

Comment 12

[Brendan Eich [:brendan]]

Comment on attachment 179672 [details] [diff] [review]
patch

Fix pre-existing misspelling of "dominant" as "dominate" in celldata.h?

a=me for 1.8b2.

/be

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Fix checked in to trunk, 2005-04-07 11:04 -0700.

Comment 14

[Bernd]

thanks

Comment 15

[John A. Bilicki III]

WOOHOO! Thanks for the fix! :-)