RESOLVED FIXED 8848
TFOOT borders are copied to THEAD and TBODY
https://bugs.webkit.org/show_bug.cgi?id=8848
Summary TFOOT borders are copied to THEAD and TBODY
Chris Bentley
Reported 2006-05-11 03:47:22 PDT
In Safari Version 2.0.3 (417.9.2), when the CSS rule "border-collapse:collapse" is applied to a TABLE and also CSS borders applied to the TFOOT element or its descendants, then the TFOOT borders are unexpectedly copied to the THEAD and TBODY elements. In the examples at http://code.clientside.net.au/safari/tablefoot.html only the TFOOT element should have red borders. Firefox 1.5 Mac renders as I expected - Opera 8.5 Mac renders in a similar way to Safari. IE 6 Windows cannot apply the borders directly to the TFOOT element but renders as expected when borders are applied to descendent cells A work-around for this bug is to apply a border with the same width to the affected collateral elements. This is not always desirable. Possibly related to http://bugzilla.opendarwin.org/show_bug.cgi?id=3699
Attachments
Patch w/change log and layout test (38.66 KB, patch)
2006-05-15 10:07 PDT, mitz
hyatt: review+
Updated test results (91.14 KB, patch)
2006-05-26 04:51 PDT, mitz
mjs: review+
mitz
Comment 1 2006-05-11 05:59:46 PDT
A fix is included in the patch for bug 6838.
mitz
Comment 2 2006-05-14 22:13:37 PDT
(In reply to comment #1) > A fix is included in the patch for bug 6838. > I was wrong.
mitz
Comment 3 2006-05-14 22:17:57 PDT
...that patch included half the fix in cellAbove/cellBelow.
mitz
Comment 4 2006-05-15 10:07:38 PDT
Created attachment 8320 [details] Patch w/change log and layout test I'm not sure the empty-section-skipping behavior for cellAbove/Below is correct (the patch maintains the current behavior).
Dave Hyatt
Comment 5 2006-05-15 11:26:42 PDT
Comment on attachment 8320 [details] Patch w/change log and layout test r=me
mitz
Comment 6 2006-05-26 04:51:53 PDT
Created attachment 8552 [details] Updated test results A bunch of tests were affected by this patch.
Maciej Stachowiak
Comment 7 2006-05-30 19:36:38 PDT
Comment on attachment 8552 [details] Updated test results r=me
David Kilzer (:ddkilzer)
Comment 8 2006-05-31 05:24:56 PDT
Reopening for manual review of test results (Attachment 8552 [details]). I'm guessing that the updated test results for this patch are okay, but in reviewing individual tests, I'm not comfortable committing the changes. (Perhaps I should open a separate bug?) It looks like there are numerous tests giving a false-positive results! For example, look at this test in Firefox 1.5.0.3 and then WebKit ToT (I'm using a locally-built r14643): LayoutTests/css2.1/t0801-c412-hz-box-00-b-a.html This test has scrollbars drawn when it should not (again, compare with Firefox 1.5.0.3): LayoutTests/fast/flexbox/016.html There is also inconsistency between the rendering of this test in Firefox 1.5.0.3 and WebKit ToT: LayoutTests/tables/mozilla/marvin/backgr_layers-opacity.html Am I insane, or do we need to manually review all of the test results to restore confidence in them?
mitz
Comment 9 2006-05-31 06:56:36 PDT
(In reply to comment #8) > I'm guessing that the updated test results for this patch are okay, but in > reviewing individual tests, I'm not comfortable committing the changes. Of the tests in the "Updated test results" patch, am I correct that the following is the only one you're uncomfortable with? > LayoutTests/tables/mozilla/marvin/backgr_layers-opacity.html The difference seems to be that WebKit doesn't paint the cell background in the border box. This probably warrants a separate bug (fixing bug 6838 only made the problem more apparent, but didn't create it).
David Kilzer (:ddkilzer)
Comment 10 2006-05-31 08:28:05 PDT
(In reply to comment #9) > (In reply to comment #8) > > I'm guessing that the updated test results for this patch are okay, but in > > reviewing individual tests, I'm not comfortable committing the changes. > > Of the tests in the "Updated test results" patch, am I correct that the > following is the only one you're uncomfortable with? > > > LayoutTests/tables/mozilla/marvin/backgr_layers-opacity.html No, all of the tests I listed seem to be broken. LayoutTests/css2.1/t0801-c412-hz-box-00-b-a.html clearly doesn't work. Again, I doubt it was the changes to this bug that caused them, though. Have these tests been broken all along (and just aren't labeled that way)? I was assuming that every test that wasn't clearly labeled as "broken" (such as some of the Mozilla table tests) was working, but I probably haven't looked at the test results this closely before. Is this not a valid assumption?
mitz
Comment 11 2006-05-31 08:42:42 PDT
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > Of the tests in the "Updated test results" patch, am I correct that the > > following is the only one you're uncomfortable with? > > > > > LayoutTests/tables/mozilla/marvin/backgr_layers-opacity.html > > No, all of the tests I listed seem to be broken. But only that one is in the patch attached to this bug. Never mind... > Have these tests been broken all along (and just aren't labeled that way)? One way to find out is to examine the svn history of the expected result, or try the test in a really old build. > I was assuming that every test that wasn't clearly labeled as "broken" (such as > some of the Mozilla table tests) was working [...] > Is this not a valid assumption? I'm afraid it isn't (I know about several tests in tables/mozilla/, I don't know about css1 and css2.1). It might be valid for the tests in fast/.
David Kilzer (:ddkilzer)
Comment 12 2006-05-31 08:48:44 PDT
(In reply to comment #11) > (In reply to comment #10) > > I was assuming that every test that wasn't clearly labeled as "broken" (such as > > some of the Mozilla table tests) was working > [...] > > Is this not a valid assumption? > > I'm afraid it isn't (I know about several tests in tables/mozilla/, I don't > know about css1 and css2.1). It might be valid for the tests in fast/. Ahh, sorry. In that case, I'll land the "Updated test results" when I get home from work unless someone beats me to it.
Note You need to log in before you can comment on or make changes to this bug.