Bug 21968 – SVG hover incorrect on a scrolled div

• Component: SVG
• Status: RESOLVED DUPLICATE

[Dean McNamee]

This demonstrates what looks to be a hit testing / coordinate bug in SVG.  The test puts an SVG element inside of a fixed size div, along with an overflow for the scroll bar.  There is a css hover attribute to color the line on mouseover.  When the div is not scrolled, everything looks fine. However, try scrolling the scroll bar to the middle, and now mouse over the line.  You can see that only half of the line is painted the hover color.

I have tested this on Chromium and Safari w/ TOT Webkit, both only tested on Windows, so it might be a Windows specific platform bug.

The mime types aren't right on the above url, so just save it and open it locally.

[Gavin Sherlock]

On the Mac (r37990) I see no line at all at the bug url.

[Dean McNamee]

Cleaned up the example a little.  Please download and view it, since Google Pages doesn't serve it with the correct mime type.  I reproduced the problem on OSX.

http://dean.googlepages.com/svgscrollbug2.xml

[Eric Seidel (no email)]

Thanks dean, that's a nice reduction.

[Eric Seidel (no email)]

Should be simple to fix.  The invalidation rect is not taking the scroll-offset into account.  This is due to SVG having a different drawing model from HTML/CSS (SVG uses full transforms, html/css in webcore until recently only used integer offsets).  We're still working on making the SVG render tree fully HTML-aware (and vice versa).

[Eric Seidel (no email)]

Created attachment 24971 [details]
test case

[Eric Seidel (no email)]

Comment on attachment 24971 [details]
test case

autofill got a bit over-zealous there.

[Eric Seidel (no email)]

I traced through the same code but using divs.  This code:

        // FIXME: We ignore the lightweight clipping rect that controls use, since if |o| is in mid-layout,
        // its controlClipRect will be wrong. For overflow clip we use the values cached by the layer.
        if (o->hasOverflowClip()) {
            // o->height() is inaccurate if we're in the middle of a layout of |o|, so use the
            // layer's size instead.  Even if the layer's size is wrong, the layer itself will repaint
            // anyway if its size does change.
            IntRect boxRect(0, 0, o->layer()->width(), o->layer()->height());
            int x = 0, y = 0;
            o->layer()->subtractScrolledContentOffset(x, y); // For overflow:auto/scroll/hidden.
            topLeft.move(x, y);
            IntRect repaintRect(topLeft, rect.size());
            rect = intersection(repaintRect, boxRect);
            if (rect.isEmpty())
                return;
        } else
            rect.setLocation(topLeft);

Is executed in RenderBox::computeAbsoluteRepaintRect (called from RenderBox ::absoluteClippedOverflowRect as part of the repaint), and is the code which does the translation of the repaint rect to account for layer scrolling.

Now the question is why does this same code not get hit from RenderSVGRoot (which is a RenderBlock, and thus a RenderBox).

[Eric Seidel (no email)]

Ok, I think it might be getting confused by the fact that RenderPath has a 0, 0 border box.  I'm not sure if SVG components really should return valid width/height for border box or not.  I'll try fixing that first.

[Eric Seidel (no email)]

This is fixed by the patch attached to bug 25268.

[Eric Seidel (no email)]

Mean to mark it as a dupe. 25268

[Eric Seidel (no email)]

*** This bug has been marked as a duplicate of 25268 ***