[webkit-dev] Bug 22759 - dropdown menu disappears on mouse-over

[David Hyatt]

Can't you just post this in the bug?  I fail to see why this should be  
a topic for discussion on webkit-dev.

dave
(hyatt at apple.com)

On Jul 5, 2009, at 1:18 PM, Vamsi Kalyan wrote:

> Hi, this post is related to issue
> https://bugs.webkit.org/show_bug.cgi?id=22759.
>
>
> corresponding chrome issue is
>
> http://code.google.com/p/chromium/issues/detail?id=2019
> 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
> 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 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?
> Thanks.
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090706/77eac725/attachment.html>