[Webkit-unassigned] [Bug 22759] dropdown menu disappears on mouse-over
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Jul 6 06:12:29 PDT 2009
https://bugs.webkit.org/show_bug.cgi?id=22759
tvk <tvamsikalyan at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tvamsikalyan at gmail.com
--- Comment #2 from tvk <tvamsikalyan at gmail.com> 2009-07-06 06:12:28 PDT ---
Following calculations calculate the expected results for the
reduction HTML file attached to the issue.
Root ListItem vertical size, "RLITotal" = 0.6em top padding + text
line height + 0.7em bottom padding, where
Text line height = 16px * 70/100 * 1.5 = 16.8
So "RLITotal" = 0.6 * 16 * 70 / 100 + 16.8 + 0.7 * 16 * 70 / 100
= 6.72 + 16.8 + 7.84
= 31.36
The absolute positioned popup list's vertical position = 2.8em
= 2.8 * 16 * 70 /100
= 31.36
Though there is no gap between root element and popup, in Chrome we
see some gap.
What happens inside code during parsing the HTML file is that floating
pointing number gets converted to integer without rounding off. So
6.72 becomes 6, 7.84 becomes 7 and 16.8 becomes 16 resulting in total
for "RLITotal" as 29.
And absolute vertical location for popup, 31.36 becomes 31.
Clearly two pixel gap results because of this rounding off behaviour.
Inside following function,
int computedLineHeight() const
{
Length lh = lineHeight();
// Negative value means the line height is not set. Use the
font's built-in spacing.
if (lh.isNegative())
return font().lineSpacing();
if (lh.isPercent())
return lh.calcMinValue(fontSize(), true);
return lh.value();
}
The line, "return lh.calcMinValue(fontSize(), true);" was changed by
adding true as second parameter, which lets the calcMinValue to round
off the result to nearest integer. So in above example 16.82 becomes
17.
But that will not be sufficient because we'll still have 1 pixel gap.
So adding 0.5 to result before casting it to integer in the following
function fixes the issue. This function is a generic function used
during HTML/CSS file parsing.
int CSSPrimitiveValue::computeLengthIntForLength(RenderStyle* style,
double multiplier)
{
double result = computeLengthDouble(style, multiplier);
// This conversion is imprecise, often resulting in values of,
e.g., 44.99998. We
// need to go ahead and round if we're really close to the next
integer value.
result += result < 0 ? -0.01 : +0.01;
if (result > intMaxForLength || result < intMinForLength)
return 0;
return static_cast<int>(result);
}
I do not know why only 0.01 was added above, what happens if we add 0.5 is to
be understood.
I am not sure how to work further on this issue to take it to some sort of
conclusion. Any help would be appreciated.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list