Bug 21968 - SVG hover incorrect on a scrolled div
Summary: SVG hover incorrect on a scrolled div
Status: RESOLVED DUPLICATE of bug 25268
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
URL: http://dean.googlepages.com/svgscroll...
Keywords:
Depends on: 23881
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-30 05:50 PDT by Dean McNamee
Modified: 2009-04-17 10:28 PDT (History)
1 user (show)

See Also:


Attachments
test case (1.11 KB, application/xml)
2008-11-07 12:52 PST, Eric Seidel (no email)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dean McNamee 2008-10-30 05:50:09 PDT
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.
Comment 1 Gavin Sherlock 2008-10-30 06:40:50 PDT
On the Mac (r37990) I see no line at all at the bug url.
Comment 2 Dean McNamee 2008-11-01 10:51:46 PDT
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
Comment 3 Eric Seidel (no email) 2008-11-05 13:36:49 PST
Thanks dean, that's a nice reduction.
Comment 4 Eric Seidel (no email) 2008-11-05 13:38:23 PST
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).
Comment 5 Eric Seidel (no email) 2008-11-07 12:52:27 PST
Created attachment 24971 [details]
test case
Comment 6 Eric Seidel (no email) 2008-11-07 12:52:47 PST
Comment on attachment 24971 [details]
test case

autofill got a bit over-zealous there.
Comment 7 Eric Seidel (no email) 2008-11-07 13:07:56 PST
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).
Comment 8 Eric Seidel (no email) 2008-11-07 13:45:59 PST
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.
Comment 9 Eric Seidel (no email) 2009-04-17 10:28:12 PDT
This is fixed by the patch attached to bug 25268.
Comment 10 Eric Seidel (no email) 2009-04-17 10:28:43 PDT
Mean to mark it as a dupe. 25268
Comment 11 Eric Seidel (no email) 2009-04-17 10:28:48 PDT

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