Bug 18437 – Mouse events occur on the wrong element when clip path is applied

• Component: SVG
• Status: RESOLVED FIXED

[Martin Booth]

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

[Rob Buis]

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.

[Eric Seidel (no email)]

Looks sane to me, but hyatt should really review this.

[Eric Seidel (no email)]

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...

[Dirk Schulze]

Fixed in trunk. Closing bug.