Last Comment Bug 315861 - SVG Mouse events inhibited by clippath in proximity
: SVG Mouse events inhibited by clippath in proximity
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 1 vote (vote)
: ---
Assigned To: tor
: Hixie (not reading bugmail)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-10 06:13 PST by JP Fiset
Modified: 2005-11-16 22:34 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Attachment to reproduce problem (26.21 KB, image/svg+xml)
2005-11-10 06:33 PST, JP Fiset
no flags Details
Simpler test case (1.93 KB, image/svg+xml)
2005-11-10 06:42 PST, JP Fiset
no flags Details
Compare using different clip paths to using the same one (1.98 KB, image/svg+xml)
2005-11-10 06:55 PST, JP Fiset
no flags Details
dirty clipPath children when hit testing (1.10 KB, patch)
2005-11-10 12:27 PST, tor
alex: review+
Details | Diff | Review

Description JP Fiset 2005-11-10 06:13:47 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

An area that is hidden in the display via a clip path inihibits the mouse events of surrounding objects. It appears to apply to all objects that fall under the original path, the part that is "clipped" away.

Reproducible: Always

Steps to Reproduce:
1. Create an object that reacts to mouse events
2. Create a second object that covers the first one.
3. Apply a clippath to the second object so that the first object is visible.
4. First object does not receive mouse events

Actual Results:  
Currently, under the scenario described above, the first object does not receive mouse events

Expected Results:  
The first object should receive mouse events

Hopefully, you can fix this before the release. We are counting on Mozilla for deploying our product, but this is a show stopper for our project since I do not think there is a work around.
Comment 1 JP Fiset 2005-11-10 06:33:26 PST
Created attachment 202509 [details]
Attachment to reproduce problem

This is quite large, but readily shows the problem
Comment 2 JP Fiset 2005-11-10 06:42:05 PST
Created attachment 202511 [details]
Simpler test case

Same problem, much simpler SVG
Comment 3 JP Fiset 2005-11-10 06:45:41 PST
This problem appears to happens only when both shape are reusing the same clip-path, and that one of the shape is moved via a transform attribute. If you take the simple test case, duplicate the clip path and assign the duplicate to one of the object, then the behaviour is what would be expected.
Comment 4 JP Fiset 2005-11-10 06:55:19 PST
Created attachment 202513 [details]
Compare using different clip paths to using the same one

This attachment provides a comparison between reusing a clip path and using different ones. Two equivalent cases are shown: one that reuses a clip path via a transform and a second, which uses two clip paths to obtain the same effect.
Comment 5 Amos Hayes 2005-11-10 08:46:18 PST
I have tried the last testcase and am able to observe the problem on Firefox 1.5 RC1 for OSX.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Comment 6 tor 2005-11-10 12:27:57 PST
Created attachment 202546 [details] [diff] [review]
dirty clipPath children when hit testing
Comment 7 tor 2005-11-16 22:34:06 PST
Checked in.

Note You need to log in before you can comment on or make changes to this bug.