RESOLVED DUPLICATE of bug 34913 Bug 28607
Body background color isn't drawn at bottom of page 
https://bugs.webkit.org/show_bug.cgi?id=28607
Summary Body background color isn't drawn at bottom of page
Jonathan del Strother
Reported 2009-08-21 01:45:07 PDT
http://audioboo.fm/login has a background colour on the body. Webkit occasionally forgets to color in the bottom half, below the actual content of the page (ie everything beneath the copyright line appears white). Resizing the window or otherwise causing a redraw fixes the problem, and the entire page gets the grey background colour. I keep seeing this in Safari/Webkit nightly builds, but can rarely reproduce it. It seems to appear much more frequently in Chrome on Windows, and Chromium on Mac. Any ideas why?
Attachments
Screen shot showing problem on an internal system - had to hide some data. note the white patch at the bottom (background should be solid gray). Safari 4.0.4 (6531.21.10), Mac OS X 10.6.3. (158.15 KB, image/png)
2010-04-25 08:44 PDT, Scott Zetlan 		no flags
Details
Reduction (622 bytes, text/html)
2010-04-26 05:51 PDT, Elliott Sprehn 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Darren Collins
Comment 1 2009-08-21 01:58:10 PDT
The two example sites https://audioboo.fm/login and http://test.longwhiteclouds.co.nz/ both have coloured backgrounds. Sometimes there is a white area at the bottom of the page instead of the coloured background. This does not happen everytime. It is fairly easy to reproduce in Chrome 2.0.172 by hitting ctrl+refresh a few times. It also occurs in Safari, but is not as easy to reproduce. Looking at the Web Inspector you can see that the coloured background only extends down as far as the computed height of the html element - below that is white.
Darren Collins
Comment 2 2009-08-21 01:58:37 PDT
*** Bug 28608 has been marked as a duplicate of this bug. ***
Gustaaf Groenendaal (MysteryQuest)
Comment 3 2009-08-23 18:34:07 PDT
Experiencing the same problem with one of my own projects. The bug seems to occur most of the time when the site is not cached and not in history, but that may also every. This bug might be completely random however.
Kevin M. Dean
Comment 4 2009-08-26 16:16:52 PDT
I've noticed this same issue with a variety of sites as well. I even saw it at least once where just the lower left corner below the content didn't draw in instead of all the way across being white.
Kevin M. Dean
Comment 5 2009-08-26 16:23:36 PDT
http://www.winningworkteams.com/ On this link I animate the content down and when the background is not drawing in, the background actually draws in in chunks as the content animates downward. Note that there's also another recent bug with this site as noted here: https://bugs.webkit.org/show_bug.cgi?id=28756
Kevin M. Dean
Comment 6 2010-01-08 06:42:04 PST
I'm still occasionally seeing this problem (also occurs under PPC as well as Intel). I did come across one thing that fixes it from the coder side. Placing the following javascript at the end of the page load probably causes a repaint. <script type="text/javascript"> document.html.style.webkitTransform = 'scale(1)'; </script>
Scott Zetlan
Comment 7 2010-04-25 08:44:32 PDT
Created attachment 54242 [details] Screen shot showing problem on an internal system - had to hide some data. note the white patch at the bottom (background should be solid gray). Safari 4.0.4 (6531.21.10), Mac OS X 10.6.3. I can reproduce this problem in Safari (4.0.4) and Chrome (5.0.342.9) on Mac OS X (10.6.3). It's intermittent, so very difficult to capture, and any action that causes the browser to redraw the window (for example, resizing the screen or obscuring and then revealing the window) makes the screen draw correctly. The background should be a solid color extending all the way to the bottom of the window, but instead I get a white patch below the table. I can't reproduce this problem in Firefox or IE (haven't tried Opera), so that suggests a webkit engine issue rather than Safari- or Chrome-specific. Happy to provide the code behind the screen, if someone wants to see it, although there's some data in the app I can't share. As a result, I've hidden the data in the screenshot via Photoshop. I can tell you I'm using divs to position tables inside the body element. HTML (XHTML 1.0 Transitional) and CSS (3.0) validated cleanly via validator.w3.org.
Elliott Sprehn
Comment 8 2010-04-26 05:51:27 PDT
Created attachment 54283 [details] Reduction I've reduced this bug and it seems to relate to having more than one script element in the <head> where the web server doesn't return cache control headers. Refresh the test page repeatedly with Apple+R to see the bug happen. Sometimes the page will load but the grey background will not cover the entire body. Resizing the window or obscuring the window with another window (anything that seems to cause a repaint) is enough to fix it.
Elliott Sprehn
Comment 9 2010-04-26 06:02:40 PDT
I believe this is related to an issue I'm seeing on sites where every page seems to flicker white for a second right before rendering. ex. http://cfunited.com/2010/prices Clicking the "Prices" link repeatedly in shipping Safari renders very smoothly without any flicker. Doing the same in Webkit Nightly produces an extremely noticeable white flash. The flicker is also noticeable when clicking between pages on the same site, not just when refreshing. (r58231, observed since at least r57284)
Will Glynn
Comment 10 2010-04-26 11:55:11 PDT
I've noticed this issue for a long time, on a wide array of websites, and didn't think much about it. However, it began to irritate me on a new website I've spent a lot of time with. I trial-and-errored a while (a pain, given the non-determinism of this bug) and eventually discovered a workaround. Rather than: body { background-color: #444; } Say: html, body { background-color: #444; } Adding this declaration seems to make this problem disappear in existing releases of Chrome and Safari, and I've found no negative effects in Webkit or other browsers thus far. CSS 2.1 confirms that styling "body" is the recommended approach, and indicates that background handling of "body" within "html" is a special case, possibly hinting at the root of this issue: For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. For documents whose root element is an HTML "HTML" element or an XHTML "html" element that has computed values of 'transparent' for 'background-color' and 'none' for 'background-image', user agents must instead use the computed value of the background properties from that element's first HTML "BODY" element or XHTML "body" element child when painting backgrounds for the canvas, and must not paint a background for that child element. [1] CSS3 agrees, though with slightly different wording. [2] [1] http://www.w3.org/TR/CSS21/colors.html#background [2] http://www.w3.org/TR/css3-background/#special-backgrounds
Alexey Proskuryakov
Comment 11 2010-04-26 13:23:20 PDT
Marking as a duplicate of newer bug that has more data in it. *** This bug has been marked as a duplicate of bug 34913 ***
Note You need to log in before you can comment on or make changes to this bug.