293422 - CSS background images that overflow body will position to the left by 1px when page has no overflow

Status: RESOLVED EXPIRED

(Core :: CSS Parsing and Computation, defect)

Description

[Rob]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

First, let's look at one of my sites with NO body overflow @ in a fairly high
resolution with Firefox in a NON maximized window: http://www.thexvector.us/ -
it appears normal enough, but notice the top background image where the two
faces appear, and in between them, there is a white X. Mouse over this X and
notice a css a:hover background image effect. Notice how when the a:hover is
invoked, the a:hover image does not fully cover the existing image, its offset
by 1px.

Second, let's go to my same site, only a different page, using the same css and
div but this time there is body overflow needed which Firefox automatically
inserts a side scroll bar to compensate for: http://www.thexvector.us/email/ -
as you can see, when the a:hover effect is invoked, the image is now fully
covered since Firefox properly adjusted the main background image.

I've tested this on most versions of Windows (except 95) and the same result has
occurred. I've also tested this using Internet Explorer 5.5 and 6, Opera 7 and
8, which properly handle the background image of the parent div container.

Taking note as this only occurs when the window is NOT maximized. After the
window is maximized, this overflow issue no longer occurs. So if you were to
view these pages in a screen resolution of say 1152x864 and the Firefox window
was adjusted to something like 800x600, this overflow issue would occur.

Reproducible: Always

Steps to Reproduce:
1. Construct an image with a dimension of 2048px by 50px to use as a background
image in a container, such as a div. Perhaps put some points of reference in
which accurate measurements could be taken, something like ruler style markings
would be good.

2. Create a basic div container and associate a css identifier with it. e.g.
<div id="testOverFlowBG"></div>

3. Create this css so it can be read by the div

html, body { /* this is to accurately reproduce how my particular css is setup */
	margin: 0 auto;
	padding: 0;
}

#testOverFlowBG {
	background: url( ../images/BGtest.gif ) center top no-repeat;
	width: 100%;
	height: 50px;
	margin: 0 auto;
	padding: 0;
}

4. Test the above with no overflow (no scroll bars) and take a measurement of
the background image from the markings on the background image as previously
noted. A screen shot is very helpful in this case.

5. Test the above with a body overflow invoked, perhaps by adding a series of
<br /> elements until the Firefox invokes its overflow to scroll the page, then
take a screen shot and measure the results.


Actual Results:  
The actual result of this body overflow bug is that it will throw a background
image off to the left by 1px when used in a container that has a 100% width
setting of the body container when the Firefox window is NOT maximized (in my
case, the image exceeds the width of the page, but is still centered in
proximity to the container it is held in). In certain instances, such as the
example given on my website, this can be annoying. Although it is not a critical
CSS bug, it should be looked into since CSS is being more widely used throughout
the Internet for layout purposes.

Expected Results:  
The background image should not move to the left or right, it should center as
defined by the CSS properties.

Feel free to use my website and examine the CSS to help resolve this minor
glitch. I hope the links and details help the Firefox developers continue to
improve the already excellent CSS support. For any questions regarding
reproduction of this overflow bug, please feel free to contact me at the e-mail
given. I would be more than happy to create a zipped version to send the
developers that accurately reproduces this in a simplified form when compared to
the CSS of my website.

Thank You,

Rob

Comment 1

[Boris Zbarsky [:bzbarsky]]

Can't reproduce with a current trunk build on Win98... Please test the Deer Park
preview?  Filing layout bugs on branch builds (which use a rendering engine from
April 2004) is pretty pointless.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.