Bug 5531 – 1px gap appears between percent-sized floats adding to 100%

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: Layout and Rendering

[Matt Wilson]

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

[Matt Wilson]

Created attachment 4507 [details]
Test Case/Reduction for bug

[Alexey Proskuryakov]

Firefox 1.0.5, MacIE and WinIE render the test without a gap; Opera 8.50 renders it like Safari.

[Eric Seidel (no email)]

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.

[Alexey Proskuryakov]

Actually, Firefox 1.5 doesn't always render this test case without a gap: it appears at certain page widths.

[Li Luo]

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

[Li Luo]

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.

[Konstantin Shcheglov]

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.

[Konstantin Shcheglov]

May be https://bugs.webkit.org/show_bug.cgi?id=60318 will fix this, or at least will make solution easier.

[Robert Hogan]

Both test cases look fine to me as of r131397. Can the reporters confirm and we can close?

[Matt Wilson]

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.)

[Li Luo]

I see gaps in both test cases, running r131989 on 10.8

[Robert Hogan]

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.

[Brent Fulgham]

Safari, Firefox, and Chrome match behavior here. Both test cases work identically on all browsers.

[Radar WebKit Bug Importer]

<rdar://problem/96543246>