With two floats, widths 22% and 78%, and floated in opposite directions, a 1 pixel gap appears between them. 22 + 78 = 100, therefore there should be no gap. Likely a rounding problem. Expected result: no gap Actual result: 1 pixel gap
Created attachment 4507 [details] Test Case/Reduction for bug
Firefox 1.0.5, MacIE and WinIE render the test without a gap; Opera 8.50 renders it like Safari.
Yes, we use integers for storing these sorts of values. It's possible this might also be due to the QRect width/height off-by-one confusion found so often in our code.
Actually, Firefox 1.5 doesn't always render this test case without a gap: it appears at certain page widths.
This bug also appears, if both divs are floated with left. The gab appears simply at end (i.e. right) of the line. Also it seems the bug does not depend on the values (22%, 78%). For example: use 50%, 50% as width. you will also see a gab at end. If you don't, resize the window and you will see the gab. Possibly it depends on whether the window's width can be divided integrally in 50%, 50%. The gab becomes bigger with number of the divs. This bug is quite anoying for peoples who try to eliminate tables from their layouts XD
Created attachment 14318 [details] testcase with more than two divs a testcase for last comment of mine. Four divs floated within a container (div). You see a gap at the end of the line/container. The gap's size changes (kind of flicker), if you resize the window.
Just for records. Problem is that integer type is used to store width and location. So, when Length::calcMinValue calculates: return static_cast<int>(static_cast<float>(maxValue * percent() / 100.0f)); For maxValue=201px we get 100 for one float 50% and for another float 50%. So, we get 1px gap at the right. I'm not sure how to solve this without using floating point. It seems that Firefox uses floating point here, because it shows 100.5px in calculated style.
May be https://bugs.webkit.org/show_bug.cgi?id=60318 will fix this, or at least will make solution easier.
Both test cases look fine to me as of r131397. Can the reporters confirm and we can close?
I just tested in r131989, and my two-div test case still shows the problem. There should be no white space between the two divs. (Note that resizing your browser window will cause the gap to appear and disappear at certain points.)
I see gaps in both test cases, running r131989 on 10.8
I though all ports were using subpixel precision but maybe that's not the case - http://trac.webkit.org/wiki/LayoutUnit. Adding Levi as this seems subpixel-related - and I can't recreate on Chrome.
Safari, Firefox, and Chrome match behavior here. Both test cases work identically on all browsers.
<rdar://problem/96543246>