Bug 21968

Summary: SVG hover incorrect on a scrolled div
Product: WebKit Reporter: Dean McNamee <deanm>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: zimmermann
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows XP   
URL: http://dean.googlepages.com/svgscrollbug.xml
Bug Depends on: 23881    
Bug Blocks:    
Attachments:
Description Flags
test case none

Dean McNamee
Reported 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.
Attachments
test case (1.11 KB, application/xml)
2008-11-07 12:52 PST, Eric Seidel (no email) 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Gavin Sherlock
Comment 1 2008-10-30 06:40:50 PDT
On the Mac (r37990) I see no line at all at the bug url.
Dean McNamee
Comment 2 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
Eric Seidel (no email)
Comment 3 2008-11-05 13:36:49 PST
Thanks dean, that's a nice reduction.
Eric Seidel (no email)
Comment 4 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).
Eric Seidel (no email)
Comment 5 2008-11-07 12:52:27 PST
Created attachment 24971 [details] test case
Eric Seidel (no email)
Comment 6 2008-11-07 12:52:47 PST
Comment on attachment 24971 [details] test case autofill got a bit over-zealous there.
Eric Seidel (no email)
Comment 7 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).
Eric Seidel (no email)
Comment 8 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.
Eric Seidel (no email)
Comment 9 2009-04-17 10:28:12 PDT
This is fixed by the patch attached to bug 25268.
Eric Seidel (no email)
Comment 10 2009-04-17 10:28:43 PDT
Mean to mark it as a dupe. 25268
Eric Seidel (no email)
Comment 11 2009-04-17 10:28:48 PDT
*** This bug has been marked as a duplicate of 25268 ***
Note You need to log in before you can comment on or make changes to this bug.