Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20090829 Minefield/3.7a1pre When using an element with a non-integer width (e.g., 9.99px) inside of an element with margin:auto, the width of the former element will change depending on the size of the window. I originally discovered this while using the Text-to-Image extension, which applies a max-width and max-height to images. Firefox will sometimes compute a non-integer width, which then triggers this bug. STR: 1) Open attached testcase 2) Adjust window width Expected: No red line appears. Actual: Red line will appear on the right side of the black square. good: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070206 Minefield/3.0a2pre bad: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070207 Minefield/3.0a3pre ...so this is probably a regression from bug 177805.

(In reply to comment #0) > When using an element with a non-integer width (e.g., 9.99px) inside of an > element with margin:auto, the width of the former element will change depending > on the size of the window. I think this is expected behavior; we snap locations to the nearest pixel, not widths. The only reasonable alternative that doesn't make 4 * 25% do horrible things (e.g., causing the fourth float to wrap some of the time) is always rounding down (which I've been told is what WebKit does)

Actually WebKit (Safari and Chrome) does not do that: it still rounds widths and heights instead of rounding computed coordinates within the viewport. There are enough demonstrations about it, where a set of 5 supposedly equal spans (subdividing a 100% width in a resizable viewport) are partly overlapping by 1 pixel and not covering a 100% horizontal or vertical spanning, leaving 1 pixel unfilled borders. The same is true about the Trident engine of IE (including in IE7 or IE8, but possibly not in the recent and impressive IE9 preview).