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

[Vamsi Kalyan]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090705/e9a049d2/attachment.html>