RESOLVED DUPLICATE of bug 9268 15036
background-image for <tbody> or <thead> is used for each <tr> in that element
https://bugs.webkit.org/show_bug.cgi?id=15036
Summary background-image for <tbody> or <thead> is used for each <tr> in that element
mupo
Reported 2007-08-21 07:07:26 PDT
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).
Attachments
Test case (386 bytes, text/html)
2009-06-26 19:08 PDT, Mark Rowe (bdash)
no flags
David Kilzer (:ddkilzer)
Comment 1 2007-08-21 09:30:31 PDT
Thanks for the bug report! Could you attach an example of this bug to this report, or provide a URL where this occurs?
Dave Hyatt
Comment 2 2007-08-21 17:36:40 PDT
This is identical to WinIE's behavior I believe.
Rene Trost
Comment 3 2008-02-11 02:37:23 PST
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.
Jasper Bryant-Greene
Comment 4 2008-10-07 13:21:40 PDT
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).
Jasper Bryant-Greene
Comment 5 2008-10-07 13:33:38 PDT
(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.
Mark Rowe (bdash)
Comment 6 2009-06-26 19:08:30 PDT
Created attachment 31970 [details] Test case Here's a test case that's a little easier on the eyes.
Jessie Berlin
Comment 7 2009-06-29 08:35:47 PDT
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.
Daniel Bates
Comment 8 2010-03-26 18:58:13 PDT
*** This bug has been marked as a duplicate of bug 9268 ***
Note You need to log in before you can comment on or make changes to this bug.