Bug 15036 – background-image for <tbody> or <thead> is used for each <tr> in that element

• Component: Tables
• Status: RESOLVED DUPLICATE

[mupo]

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).

[David Kilzer (:ddkilzer)]

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]

This is identical to WinIE's behavior I believe.

[Rene Trost]

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]

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]

(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)]

Created attachment 31970 [details]
Test case

Here's a test case that's a little easier on the eyes.

[Jessie Berlin]

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]

*** This bug has been marked as a duplicate of bug 9268 ***