If there is a an svg element which has an onclick event applied to it, and it has a clip path applied, then the onclick even fires when you click on the elements original shape, including areas which have been made invisible by the by the clip path. Steps to reproduce.. to svg elemens of the same shape and size placed on top of each other.. apply a clip path to the top most element so part of the element underneath is now visible, and apply onclick events to both of these elements.. the onclick event on the element at the bottom won't fire like it does in other browsers
Created attachment 20499 [details] First attempt I am attaching the code first for my patch, since I want to check whether I have the right approach. The testcases will probably be a lot of work, but I have some good ideas what to test. Cheers, Rob.
Looks sane to me, but hyatt should really review this.
Comment on attachment 20499 [details] First attempt Looks OK, but needs more thought than I have brain cells for atm. First, your doubtful comments about absolute-to-local conversions aren't needed. :) Yes in inverse of the absoluteTransform is exactly what will convert from screen chords to local coords for the element in question. :) This needs test cases. Not sure how fast/slow this is. This doesn't work for TextClips or clips which can't convert to a path object (which we have a separate bug about fixing somewhere). I think if you're in the clipping code you should be at least aware of these other bugs: bug 12571, bug 14015 and bug 18398 why wouldn't "clipContains" just be on RenderObject? (or is there a RenderSVGObject yet... I guess not). I guess I'll go ahead and r- this for lack of test case. The best way to fix this IMO, would be to make sure that any fix moves us closer to an architecture which we can solve bug 12571 under (Which means asking the clipper if they contain a point, instead of asking them for their path first... which I guess you're already sorta doing.) Maybe I'm just too tired...
Fixed in trunk. Closing bug.