Bug 16483
| Summary: | SVG should allow clicks to "fall through" to XHTML content when transparent | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | SVG | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | hyatt, ian, timur.mehrvarz |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
| URL: | http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-focusable-points.xhtml | ||
| Bug Depends on: | |||
| Bug Blocks: | 15836 | ||
Eric Seidel (no email)
http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/wicdcore.xhtml#core14
http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-focusable-points.xhtml
I'm not sure how complicated this will be.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Eric Seidel (no email)
Ok, I think this test is wrong.
http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-focusable-points.xhtml
The event should dispatch to the front-most element under that mouse location. (I'm sure there is a spec which says this.)
In this case, that's the SVG <rect> element which is semi-transparent. Since pointer-events defaults to "visiblePainted" the <rect> element can actually accept events, and thus the hit testing stops. An event is dispatched up the tree to the <rect> element, through the <object> and <svg> elements, but NOT touching the <html:a> elements which are not in the ancestor tree for the <rect>. Then the event bubbles back down through the same tree, again, never touching the <html:a> elements.
If the <rect> had pointer-events="none" specified, then it would fail to hit-test and the <html:a> element should actually be clickable.
We still fail this test with pointer-events="none", not sure why. That might be real bug on our part, or I might be misinterpreting how hit testing should actually work.
Eric Seidel (no email)
Ok, I've looked into this more w/ our implementation. Even when the <svg> declines hit-testing via pointer-events="none", the <object> itself is still hit. Which makes some sense. At least it would make sense for an absolutely positioned empty <object> to block any mouse events from reaching elements below it. But perhaps in this case, since the <object> is just a container, if its kids fail to hit test, it should also fail.
Eric Seidel (no email)
To "fix" this would simply require overriding nodeAtPoint in RenderPartObject, RenderPart, or RenderReplaced (probably RenderPart) to only hit-or-not depending on what its child render objects say, except in the case of fallback content, where it should probably participate in hit-testing like normal.
Eric Seidel (no email)
I CC'd hyatt so that he can comment on if he feels <object> should be accepting the click event itself when its kids refuse it.
Ian 'Hixie' Hickson
What do the specs say? I seem to recall SVG has some sort of rule about events always hitting the "canvas" and going to the root element or something. Anyway CSS doesn't define hit-testing, we should really come up with a spec to define this sometime.
Eric Seidel (no email)
AFAICT the clicks should always hit the <object> element. Until this is specified otherwise, I think this should be closed as invalid.