Closed Bug 230101 Opened 21 years ago Closed 15 years ago

wrong behaviour of centering block and positioned background of odd width

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugzilla, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(1 file)

Testcase with two divs and two backgrounds. For divs of odd width, the background peeks out sometimes
8.97 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.5) Gecko/20031007

You have <body> element with horizontally centered background image.
And some <div> element with background image.

If both images have not odd width then appeares 1px positioning problem.




Reproducible: Always

Steps to Reproduce:
1. Open http://www.zsmilicov.cz/met/pub/positioning/testcase2.html
2. Look at the dark blue rectangle
3. Change slowly the width of the Browser window

Actual Results:  
You can see the dark blue rectangle is sometimes shifted by 1px to the left -
depending on the windows width.

Expected Results:  
This problem never happened if both pictures have even width - testcase
http://www.zsmilicov.cz/met/pub/positioning/testcase.html

Some testcases: http://www.zsmilicov.cz/met/pub/positioning/
Present on
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031208

Sounds kinda like a rounding error to me.
Status: UNCONFIRMED → NEW
Depends on: 63336
Ever confirmed: true
Keywords: testcase
I have a feeling this bug is not due to rounding 'errors' per se, but rather that in one case, we are rounding up, and rounding down in the other. Which should make this bug fairly easy to fix. 

The gain in doing so would be fairly high as this technique is very useful when you're creating hovers in menu's with the menu items scattered all over the place: just hook one image to all menu items and background-attach the hover in the center of the document and. This saves you from writing a lot of style and calculating the offsets from the top of the image, OR from creating separate images for each menu item. 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

Both examples in the testcase now exhibit this behaviour, I think the cause of this is the patch on bug 433640
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0

Correct behaviour in this version
I'm experiencing a similar bug. It's a one pixel difference in centering between the CSS centering with "margin: 0 auto" and image "centering with background-position: center" that happens on odd browser window width.

See the demo and a brief description here: http://piotr.gabryjeluk.pl/firefox-bug
I am experiencing the same bug in version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

The "margin:auto" block element is rounded to the right, and the centered body background is rounded to the left.
For me it's an issue using

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1) Gecko/2008071717 Firefox/3.0.1
i see this bug too.....when I develop sites, it's real problem...
Hopefully this is fixed by roc's recent changes (for 3.1); if so, good to get an automated test for it if we don't have one already.
Flags: in-testsuite?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090328 Shiretoko/3.5b4pre

Confirmed fixed on this build. What revision was this fixed in?
good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0a1pre) Gecko/2008022002 Minefield/4.0a1pre

This is fixed in the earliest available nightly for 3.1. Resolving worksforme.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
(In reply to comment #13)
> good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:2.0a1pre)
> Gecko/2008022002 Minefield/4.0a1pre
> 
> This is fixed in the earliest available nightly for 3.1. Resolving worksforme.

That nightly was well before anyone had landed any changes to 3.1, so it should have basically been the same as 3.0 (until the beginning of June).

I'd have expected the behavior to change with http://hg.mozilla.org/mozilla-central/rev/b9fd38b8f1e0 (bug 433640), and then again with http://hg.mozilla.org/mozilla-central/rev/49dd935efff3 (bug 458487).
Ahh, that makes more sense. I had missed that this was a regression (there are really two different bug reports here).

good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008060312 Minefield/3.1a1pre
bad: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008060403 Minefield/3.1a1pre
bad: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081104 Minefield/3.1b2pre
good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre
good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1pre) Gecko/2008063009 GranParadiso/3.0.1pre
bad: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1pre) Gecko/2008070106 GranParadiso/3.0.1pre

So the original bug was probably fixed by bug 177805, then this was broke again by bug 433640, then was fixed by bug 458487.
Blocks: 433640
Depends on: 458487
Keywords: regression
OS: Windows 2000 → All
Hardware: x86 → All
Resolution: WORKSFORME → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: