15036 2007-08-21 07:07:26 -0700 background-image for <tbody> or <thead> is used for each <tr> in that element 2010-03-26 18:58:13 -0700 1 1 1 Unclassified WebKit Tables 523.x (Safari 3) Mac (Intel) All RESOLVED DUPLICATE 9268 P2 Major --- 1 mupo webkit-unassigned dbates jasper jberlin mrowe t.bussmann oldest_to_newest 1806 0 mupo 2007-08-21 07:07:26 -0700 Using an background-image for <tbody> or <thead> is used for each <tr> in that element. Happens also in Safari 2.0.4 (419.3) on Mac OS X (10.4.10) and actual nightly build on Windows (r25168). 1789 1 ddkilzer 2007-08-21 09:30:31 -0700 Thanks for the bug report! Could you attach an example of this bug to this report, or provide a URL where this occurs? 1751 2 hyatt 2007-08-21 17:36:40 -0700 This is identical to WinIE's behavior I believe. 70220 3 r.trost 2008-02-11 02:37:23 -0800 I can confirm this bug with OSX 10.4.11 - Safari 3.0.4 (523.12.2). Example is available here: http://www.syncbyte.com/tbody_bg.html The background image is only set to TBODY (even with no-repeat) but gets repeated in every TR WinIE 7 repeats the background in every TR too. FF 2.x shows it correctly and doesn't repeat the background image in every TR. 94423 4 jasper 2008-10-07 13:21:40 -0700 I can confirm this bug on Safari 3.1.2 and on the latest WebKit nightly on Mac OS X 10.5.5. background-image is inherited when it should not be; I have tested and confirmed inheritance from <tbody>/<thead> to <tr> as described in this bug and also from <tr> to <td> (which was the problem that lead me to search for this bug). 94430 5 jasper 2008-10-07 13:33:38 -0700 (In reply to comment #3) > The background image is only set to TBODY (even with no-repeat) but gets > repeated in every TR FYI no-repeat refers to repetition /within the element/ if the image is smaller than the element. It's nothing to do with inheritance. 128630 6 31970 mrowe 2009-06-26 19:08:30 -0700 Created attachment 31970 Test case Here's a test case that's a little easier on the eyes. 128814 7 jberlin 2009-06-29 08:35:47 -0700 Mark and I took a look at this on Friday night, and it appears that the reason this is happening is that in the call to: void RenderBoxModelObject::calculateBackgroundImageGeometry(const FillLayer* bgLayer, int tx, int ty, int w, int h, IntRect& destRect, IntPoint& phase, IntSize& tileSize) the phase, which is then used to determine the offset into the background image in RenderBoxModelObject::paintFillLayerExtended, is getting set to the top left corner of the image on each cell paint. This is because the x and y positions of the bgLayer are initialized in to the top left corner of the image and never changed between cell paints, and they are used calculate the phase. Since paintFillLayerExtended is used in so many other places, it would probably be best to modify the xPosition and yPosition of the bgLayer in RenderTableCell::paintBackgroundsBehindCell on a per cell basis, based on what colgroup and section that cell belongs to. We found that modifying the x and y positions of the bgLayer in RenderTableCell::paintBackgroundsBehindCell right before the call to paintFillLayers could make it exhibit the correct behavior (the numbers 555 and 979 were the hard coded width and height of the image used in the test case attached to this bug): if (backgroundObject != this) { // If we're in a column group, we need to the x offset to be // relative to the left of the column group. // We can do this by walking backwards through the columns until // we hit one that is the start of a column group. // table()->colElement(col(), &isFirstInColGroup, 0) // getColumnPos(someColumnIndex) const_cast<FillLayer*>(bgLayer)->setXPosition(Length(-x() + 555, Fixed)); const_cast<FillLayer*>(bgLayer)->setYPosition(Length(-y() + 979, Fixed)); } paintFillLayers(paintInfo, c, bgLayer, my, mh, tx, ty, w, h); some logic will be needed, as described in the comment, to determine correctly based on the column group what offset into the image the phase should start at. 204908 8 dbates 2010-03-26 18:58:13 -0700 *** This bug has been marked as a duplicate of bug 9268 *** 31970 2009-06-26 19:08:30 -0700 2009-06-26 19:08:30 -0700 Test case test.html text/html 386 mrowe PHN0eWxlIHR5cGU9InRleHQvY3NzIj4KICAgIHRhYmxlIHsgd2lkdGg6IDUwJTsgYm9yZGVyLWNv bGxhcHNlOiBjb2xsYXBzZTsgfQogICAgdGhlYWQgeyBiYWNrZ3JvdW5kOiB1cmwoaHR0cDovL2Jk YXNoLm5ldC5uei9pbWFnZXMvbW91bnRhaW4tYmFja2dyb3VuZC5qcGcpOyB9CiAgICB0ciB7IGhl aWdodDogNWVtOyB9Cjwvc3R5bGU+Cgo8dGFibGU+CiAgICA8dGhlYWQ+CiAgICAgICAgPHRyPgog ICAgICAgICAgICA8dGQ+QTE8L3RkPgogICAgICAgICAgICA8dGQ+QTI8L3RkPgogICAgICAgIDwv dHI+CiAgICAgICAgPHRyPgogICAgICAgICAgICA8dGQ+QjE8L3RkPgogICAgICAgICAgICA8dGQ+ QjI8L3RkPgogICAgICAgIDwvdHI+CiAgICA8L3RoZWFkPgo8L3RhYmxlPgo=