21968 2008-10-30 05:50:09 -0700 SVG hover incorrect on a scrolled div 2009-04-17 10:28:48 -0700 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) PC Windows XP RESOLVED DUPLICATE 25268 http://dean.googlepages.com/svgscrollbug.xml P2 Normal --- 23881 1 deanm webkit-unassigned zimmermann oldest_to_newest 97111 0 deanm 2008-10-30 05:50:09 -0700 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. 97113 1 gsherloc 2008-10-30 06:40:50 -0700 On the Mac (r37990) I see no line at all at the bug url. 97374 2 deanm 2008-11-01 10:51:46 -0700 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 97731 3 eric 2008-11-05 13:36:49 -0800 Thanks dean, that's a nice reduction. 97732 4 eric 2008-11-05 13:38:23 -0800 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). 97959 5 24971 eric 2008-11-07 12:52:27 -0800 Created attachment 24971 test case 97960 6 24971 eric 2008-11-07 12:52:47 -0800 Comment on attachment 24971 test case autofill got a bit over-zealous there. 97961 7 eric 2008-11-07 13:07:56 -0800 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). 97965 8 eric 2008-11-07 13:45:59 -0800 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. 117934 9 eric 2009-04-17 10:28:12 -0700 This is fixed by the patch attached to bug 25268. 117935 10 eric 2009-04-17 10:28:43 -0700 Mean to mark it as a dupe. 25268 117936 11 eric 2009-04-17 10:28:48 -0700 *** This bug has been marked as a duplicate of 25268 *** 24971 2008-11-07 12:52:27 -0800 2008-11-07 12:52:47 -0800 test case svgscrollbug.xml application/xml 1134 eric PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbDpsYW5nPSJlbiIg bGFuZz0iZW4iPiAKPGhlYWQ+IAogIDx0aXRsZT5TVkcgc2Nyb2xsIGhvdmVyIGJ1ZzwvdGl0bGU+ IAoKICA8c3R5bGU+CiAgICBAbmFtZXNwYWNlIHVybChodHRwOi8vd3d3LnczLm9yZy8xOTk5L3ho dG1sKTsKICAgIEBuYW1lc3BhY2Ugc3ZnIHVybChodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2Zyk7 CiAgICBzdmd8bGluZSB7CiAgICAgIHN0cm9rZTogcmVkOwogICAgICBzdHJva2Utd2lkdGg6IDJw eDsKICAgIH0KCiAgICBzdmd8bGluZTpob3ZlciB7CiAgICAgIHN0cm9rZTogeWVsbG93OwogICAg fQogICAgZGl2LnN2Z2RpdiB7CiAgICAgIHdpZHRoOiA2MDBweDsKICAgICAgb3ZlcmZsb3c6IGF1 dG87CiAgICB9CiAgPC9zdHlsZT4KCjwvaGVhZD4gCgo8Ym9keT4KCjxwPgogIFRoaXMgZGVtb25z dHJhdGVzIHdoYXQgbG9va3MgdG8gYmUgYSBoaXQgdGVzdGluZyAvIGNvb3JkaW5hdGUgYnVnIGlu IFNWRy4KICBUaGUgdGVzdCBwdXRzIGFuIFNWRyBlbGVtZW50IGluc2lkZSBvZiBhIGZpeGVkIHNp emUgZGl2LCBhbG9uZyB3aXRoIGFuCiAgb3ZlcmZsb3cgZm9yIHRoZSBzY3JvbGwgYmFyLiAgVGhl cmUgaXMgYSBjc3MgaG92ZXIgYXR0cmlidXRlIHRvIGNvbG9yIHRoZQogIGxpbmUgb24gbW91c2Vv dmVyLiAgV2hlbiB0aGUgZGl2IGlzIG5vdCBzY3JvbGxlZCwgZXZlcnl0aGluZyBsb29rcyBmaW5l LgogIEhvd2V2ZXIsIHRyeSBzY3JvbGxpbmcgdGhlIHNjcm9sbCBiYXIgdG8gdGhlIG1pZGRsZSwg YW5kIG5vdyBtb3VzZSBvdmVyIHRoZQogIGxpbmUuICBZb3UgY2FuIHNlZSB0aGF0IG9ubHkgaGFs ZiBvZiB0aGUgbGluZSBpcyBwYWludGVkIHRoZSBob3ZlciBjb2xvci4KPC9wPgoKPGRpdiBjbGFz cz0iY29udGFpbmVyIj4KICA8ZGl2IGNsYXNzPSJzdmdkaXYiPgogICAgPHN2ZyB4bWxucz0iaHR0 cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSIxMDAwIiBoZWlnaHQ9IjMwMCI+CiAgICAg IDxsaW5lIGNsYXNzPSJldmVudGxpbmUiIHgxPSIzMDAiIHkxPSIzIiB4Mj0iODAwIiB5Mj0iNDAw IiAvPgogICAgPC9zdmc+CiAgPC9kaXY+CjwvZGl2PgoKPC9ib2R5PiAKPC9odG1sPiAK