Bug 50240

Summary: Unable to indirectly animate visibility of SVGUseElement
Product: WebKit Reporter: ken
Component: SVGAssignee: Rob Buis <rwlbuis>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, leo.yang, marek.raida, mdelaney7, rwlbuis, zimmermann
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac (Intel)   
OS: OS X 10.6   
Bug Depends on:    
Bug Blocks: 52630    
Attachments:
Description Flags
Broken behavior testcase, behaves the same bad way also on Windows platform...
none
Patch
zimmermann: review-
Revised patch version 2
zimmermann: review-
Revised patch version 3 none

ken
Reported 2010-11-30 07:43:00 PST
When viewing the SVG below, the red rectangle should disappear at 3s. The red rectangle is referenced by a <use>. The <use> is contained inside a <g>. The visibility of the <g> is set to hidden at 3s. <svg width="100%" height="100%" viewBox="0 0 1000 800" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <defs> <rect id="r" x="100" y="100" width="800" height="600" fill="red" stroke="none"/> </defs> <g> <use xlink:href="#r"/> <set attributeType="XML" attributeName="visibility" to="hidden" begin="3s"/> </g> </svg> Works with Safari 4.0.5 (531.22.7), Windows XP Doesn't work with Chrome 7.0.517.44, Windows XP Safari 5.0.3 (6533.19.4), Mac OS X 10.6 A subsequent browser Zoom causes the red rectangle to disappear. The <set> animation does work when directly targeting the <use> <use xlink:href="#r"> <set attributeType="XML" attributeName="visibility" to="hidden" begin="3s"/> </use>
Attachments
Broken behavior testcase, behaves the same bad way also on Windows platform... (15.02 KB, image/svg+xml)
2010-12-05 04:37 PST, marek
no flags
Patch (6.28 KB, patch)
2011-01-13 00:52 PST, Leo Yang
zimmermann: review-
Revised patch version 2 (5.28 KB, patch)
2011-01-16 18:59 PST, Leo Yang
zimmermann: review-
Revised patch version 3 (5.28 KB, patch)
2011-01-17 18:27 PST, Leo Yang
no flags
marek
Comment 1 2010-12-05 04:36:46 PST
Yes, I noticed the same buggy behavior in my game http://svg.kvalitne.cz/submarine/index.htm, which makes it unplayable at all.. :-( I'm enclosing similar testcase extracted from my game...
marek
Comment 2 2010-12-05 04:37:44 PST
Created attachment 75627 [details] Broken behavior testcase, behaves the same bad way also on Windows platform...
Leo Yang
Comment 3 2011-01-13 00:52:40 PST
Nikolas Zimmermann
Comment 4 2011-01-13 15:24:46 PST
Comment on attachment 78781 [details] Patch Excellent catch! Code r+, Test r-> It's a pity that we need platform dependant results, maybe you could come up with a testcase that avoids font-size changes? Can't you trigger the bug with parent fill='..' changes, or sth. else like stroke-width?
Leo Yang
Comment 5 2011-01-16 18:59:03 PST
Created attachment 79120 [details] Revised patch version 2 Using fill = "..." is a good idea. Maybe we don't need platform dependent test case because dumRenderTree can produce filling color in text.
Nikolas Zimmermann
Comment 6 2011-01-17 08:16:25 PST
Comment on attachment 79120 [details] Revised patch version 2 View in context: https://bugs.webkit.org/attachment.cgi?id=79120&action=review Excellent, almost r+. Our common style is to indidicate a "green rect" as success in the expected.png/txt files. Yours is red, please change the transition from black -> red, to red -> green, then I'll r+/cq+ it. Thanks for your patience :-) > LayoutTests/svg/custom/use-inherit-style.svg:8 > + <rect id="rect" x="0" y="0" width="100" height="60" /> Here you should use fill="red" as initial value... > LayoutTests/svg/custom/use-inherit-style.svg:17 > + document.getElementById("g").setAttribute("fill", "red"); ... and change it to fill="green" here.
Leo Yang
Comment 7 2011-01-17 18:27:04 PST
Created attachment 79235 [details] Revised patch version 3 We can't set initial fill value for the rectangle because otherwise the rectangle will not inherit fill property of <g> element. Using "green" causes 0x008000 color value which isn't consistent with the existing truly green png, so 0x00FF00 is used explicitly.
Nikolas Zimmermann
Comment 8 2011-01-18 07:29:59 PST
(In reply to comment #7) > Created an attachment (id=79235) [details] > Revised patch version 3 > > We can't set initial fill value for the rectangle because otherwise the rectangle will not inherit fill property of <g> element. Using "green" causes 0x008000 color value which isn't consistent with the existing truly green png, so 0x00FF00 is used explicitly. I'm sorry, with 'truly green' I meant the "green" color value, 0x008000. Using "green" is perfectly fine.
Nikolas Zimmermann
Comment 9 2011-01-18 07:30:52 PST
Comment on attachment 79235 [details] Revised patch version 3 I don't care though whether the rect is 00FF00 or just 00FF00, either is fine, so r=me.
WebKit Commit Bot
Comment 10 2011-01-18 07:57:16 PST
Comment on attachment 79235 [details] Revised patch version 3 Clearing flags on attachment: 79235 Committed r76027: <http://trac.webkit.org/changeset/76027>
WebKit Commit Bot
Comment 11 2011-01-18 07:57:21 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.