Bug 16483 - SVG should allow clicks to "fall through" to XHTML content when transparent
Summary: SVG should allow clicks to "fall through" to XHTML content when transparent
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.w3.org/2004/CDF/TestSuite/...
Depends on:
Blocks: 15836
  Show dependency treegraph
Reported: 2007-12-17 14:39 PST by Eric Seidel (no email)
Modified: 2008-01-19 02:20 PST (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Eric Seidel (no email) 2007-12-18 16:11:17 PST
Ok, I think this test is wrong.


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.
Comment 2 Eric Seidel (no email) 2007-12-18 16:20:45 PST
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.
Comment 3 Eric Seidel (no email) 2007-12-18 16:24:43 PST
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.
Comment 4 Eric Seidel (no email) 2007-12-25 23:30:08 PST
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.
Comment 5 Ian 'Hixie' Hickson 2007-12-26 13:16:41 PST
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.
Comment 6 Eric Seidel (no email) 2008-01-19 02:20:16 PST
AFAICT the clicks should always hit the <object> element.  Until this is specified otherwise, I think this should be closed as invalid.