Summary: | SVG hover incorrect on a scrolled div | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Dean McNamee <deanm> | ||||
Component: | SVG | Assignee: | 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
Dean McNamee
2008-10-30 05:50:09 PDT
On the Mac (r37990) I see no line at all at the bug url. 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 Thanks dean, that's a nice reduction. 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). Created attachment 24971 [details]
test case
Comment on attachment 24971 [details]
test case
autofill got a bit over-zealous there.
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). 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. This is fixed by the patch attached to bug 25268. Mean to mark it as a dupe. 25268 *** This bug has been marked as a duplicate of 25268 *** |