Bug 15036 - background-image for <tbody> or <thead> is used for each <tr> in that element
Summary: background-image for <tbody> or <thead> is used for each <tr> in that element
Status: RESOLVED DUPLICATE of bug 9268
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tables (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh Intel All
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-21 07:07 PDT by mupo
Modified: 2010-03-26 18:58 PDT (History)
5 users (show)

See Also:


Attachments
Test case (386 bytes, text/html)
2009-06-26 19:08 PDT, Mark Rowe (bdash)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description mupo 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).
Comment 1 David Kilzer (:ddkilzer) 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?
Comment 2 Dave Hyatt 2007-08-21 17:36:40 PDT
This is identical to WinIE's behavior I believe.

Comment 3 Rene Trost 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.


Comment 4 Jasper Bryant-Greene 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).
Comment 5 Jasper Bryant-Greene 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.
Comment 6 Mark Rowe (bdash) 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.
Comment 7 Jessie Berlin 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.
Comment 8 Daniel Bates 2010-03-26 18:58:13 PDT

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