[webkit-dev] Bug 22759 - dropdown menu disappears on mouse-over
hyatt at apple.com
Mon Jul 6 01:07:03 PDT 2009
Can't you just post this in the bug? I fail to see why this should be
a topic for discussion on webkit-dev.
(hyatt at apple.com)
On Jul 5, 2009, at 1:18 PM, Vamsi Kalyan wrote:
> Hi, this post is related to issue
> corresponding chrome issue is
> This post discusses the issue using the reduction HTML file
> available on the issue.
> 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
> 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 am not sure how critical the comment is in above function. Code
> rounds off only if it is too close to integer. Could anyone tell more
> about it, as in why 0.01 why not 0.5?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev