|Summary:||1px gap appears between percent-sized floats adding to 100%|
|Product:||WebKit||Reporter:||Matt Wilson <matt>|
|Component:||Layout and Rendering||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Minor||CC:||ian, leviw, robert, scheglov, waldelefant+bugzilla|
|OS:||OS X 10.4|
|Bug Depends on:||5164|
Description Matt Wilson 2005-10-28 03:24:15 PDT
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
Comment 1 Matt Wilson 2005-10-28 03:26:30 PDT
Created attachment 4507 [details] Test Case/Reduction for bug
Comment 2 Alexey Proskuryakov 2005-10-29 10:50:04 PDT
Firefox 1.0.5, MacIE and WinIE render the test without a gap; Opera 8.50 renders it like Safari.
Comment 3 Eric Seidel (no email) 2005-12-27 15:44:29 PST
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.
Comment 4 Alexey Proskuryakov 2007-03-31 11:42:39 PDT
Actually, Firefox 1.5 doesn't always render this test case without a gap: it appears at certain page widths.
Comment 5 Li Luo 2007-05-03 07:53:43 PDT
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
Comment 6 Li Luo 2007-05-03 08:03:01 PDT
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.
Comment 7 Konstantin Shcheglov 2011-09-26 08:53:06 PDT
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.
Comment 8 Konstantin Shcheglov 2011-10-05 11:41:11 PDT
May be https://bugs.webkit.org/show_bug.cgi?id=60318 will fix this, or at least will make solution easier.
Comment 9 Robert Hogan 2012-10-19 10:36:48 PDT
Both test cases look fine to me as of r131397. Can the reporters confirm and we can close?
Comment 10 Matt Wilson 2012-10-20 14:26:00 PDT
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.)
Comment 11 Li Luo 2012-10-20 14:40:14 PDT
I see gaps in both test cases, running r131989 on 10.8