16483 2007-12-17 14:39:55 -0800 SVG should allow clicks to "fall through" to XHTML content when transparent 2008-01-19 02:20:16 -0800 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Mac OS X 10.4 RESOLVED INVALID http://www.w3.org/2004/CDF/TestSuite/WICD_CDR_WP1/test-focusable-points.xhtml P2 Normal --- 15836 1 eric webkit-unassigned hyatt ian timur.mehrvarz oldest_to_newest 64575 0 eric 2007-12-17 14:39:55 -0800 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. 64677 1 eric 2007-12-18 16:11:17 -0800 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. 64679 2 eric 2007-12-18 16:20:45 -0800 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. 64681 3 eric 2007-12-18 16:24:43 -0800 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. 65271 4 eric 2007-12-25 23:30:08 -0800 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. 65303 5 ian 2007-12-26 13:16:41 -0800 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. 67679 6 eric 2008-01-19 02:20:16 -0800 AFAICT the clicks should always hit the <object> element. Until this is specified otherwise, I think this should be closed as invalid.