Bug 3998 – Absolutely positioned backgrounds tile incorrectly

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[John Whittet]

The bug occurs when a background is positioned on the body element at absolute coordinates and 
given a background-repeat value of repeat-y or no-repeat.

When the window's width is reduced to less than that of the background image, the image appears to 
tile using a different background-repeat value (repeat-x for no-repeat and repeat for repeat-y).

Neither the x or y-coordinates seem to matter. The width of the background image appears to only 
affect the minimum width of the window before the bug will manifest itself. The height of the image 
does not seem to matter.

This does not appear to occur in the y-direction (height of the background + height of the window + 
repeat-x/no-repeat).

[John Whittet]

Created attachment 2960 [details]
Screenshot - Normal

[John Whittet]

Created attachment 2962 [details]
Screenshot - Bug Manifested

[John Whittet]

Created attachment 2963 [details]
Test Case - HTML + image

[Stuart Morgan]

Confirmed in 9/2 ToT.

[John Lascurettes]

Bug actually manifests itself on the y-axis as well when the background is applied to a DIV. Attaching a test case...

[John Lascurettes]

Created attachment 8378 [details]
Test case to show both x- and y-axis behavior of bug

[John Lascurettes]

Comment on attachment 8378 [details]
Test case to show both x- and y-axis behavior of bug

The behavior seems to be fixed in later WebKit builds. Should be marked as fixed?

[Alexey Proskuryakov]

The original test case (from bug URL) still fails for me in ToT. See also: bug 3237.

[John Lascurettes]

Ah, yes. I see it happens on the BODY element still when the declaration is set to repeat-y; however, if I set it to no-repeat, it behaves as it should in ToT with the first attachment (id=2962). Experimenting a bit, the x-axis seems perfectly stable as well (setting the position such that it would reveal a bug in repeat-y if the body height was smaller than the height of background image). So it seems isolated to making a repeat-y declaration and not a declaration of no-repeat now.

[John Lascurettes]

(In reply to comment #9)
Sorry, I meant attachment 2963 [details].

[John Lascurettes]

Further exploration shows the bug for the background declaration on the BODY behaves exactly the same if applied instead to the HTML or a DIV element as well. That is, if the background-repeat is set to repeat-y, the background can be made to repeat on the x-axis. If it is set to no-repeat, I do not see the bug manifest as originally described.

There _is_ an additional behavior appearing on the y-axis that is evident if looked when the behavior is tested on a DIV element (see attachment 8378 [details]). If: 
- the background-repeat is set to no-repeat and
- the height of the containing element is more than the height of the background image but
- the height of the containing element is less than the height of the background image plus its vertical offset: 
- - then you will see that the overflow for the background of the containing element is visible (otherwise, if the element is taller or shorter than the dimensions shown above, it is hidden)

[John Lascurettes]

Created attachment 10534 [details]
image file for test case

[John Lascurettes]

Created attachment 10535 [details]
image file for test case

[John Lascurettes]

Created attachment 10536 [details]
Modified test case to show various background bug scenarios

This modified test case shows various bugs depending on background position, including negative positioning.

[John Lascurettes]

(In reply to comment #14)

The test case attachment might require a window resizing in both Safari and Nightly Builds to properly reveal the bug in the far-upper-right table cell (+150%, large parent, small background-image).

[Dave Hyatt]

I'm a bit overwhelmed by test cases here.  Can you produce a minimal test case just illustrating precisely whatever bugs still occur in the nightlies?

[John Lascurettes]

(In reply to comment #16)
> I'm a bit overwhelmed by test cases here.  Can you produce a minimal test case
> just illustrating precisely whatever bugs still occur in the nightlies?

Sorry about that. Attaching a new reduced test.

[John Lascurettes]

Created attachment 10692 [details]
Update of attachment 10536 [details]

[John Lascurettes]

Created attachment 10693 [details]
Update of attachment 10536 [details]

Sorry, there were some errors in the content description of attachment 10692 [details]; the tests were still valid, now the descriptive text matches the actual markup.

*** Bug 11458 has been marked as a duplicate of this bug. ***

I think the patch for bug 5399 might address this. Need to check this bug again after that bug is fixed.

[Mark Rowe (bdash)]

Bug 5399 is fixed, so the status of this bug should be reevaluated.

[John Lascurettes]

(In reply to comment #22)
> Bug 5399 is fixed, so the status of this bug should be reevaluated.
> 

Is bug 5399 fixed? In the latest nightly downloaded 7 Feb 2007 the test case on that bug http://bugs.webkit.org/attachment.cgi?id=12355 still shows it broken. 

So does the test case I posted for this bug http://bugs.webkit.org/attachment.cgi?id=10693

[Mark Rowe (bdash)]

As per my comment in bug 5399:
> The fix was landed less than an hour ago.  The latest nightly build is older
> than that which means it doesn't contain the fix.  Please check again with the
> next nightly build which should be available within the next half hour.

[John Lascurettes]

Yes, appears fixed.