[Bug 18912] [Shadow]: ShadowRoot needs to support elementFromPoint

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18912

--- Comment #7 from Daniel Freedman <dfreedm@chromium.org> 2012-10-01 20:00:11 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > In that case, the most logical spot to add an event listener would be in the
> > ShadowRoot that contains the element, which would then have the correct scope
> > for an elementFromPoint call.
> 
> Events get routed through <content> and <shadow> elements, so returning the
> <content> or <shadow> element is more precise than the shadow root.
> 
> However since <content> and <shadow> are not themselves rendered, it gives you
> the weird situation where you ask shadow.elementAtPoint(10, 50) and the
> offset/client properties of the result say the element is at (0,0)-(0,0).
> 
> Would that be a problem?

No, that would be fine for my case. A developer would have the same sort of
differences in the offset/client properties if the element in question was
transformed.

> 
> It seems like since you are already writing code that is dealing with
> ShadowRoot to call shadow.elementFromPoint instead of
> document.elementFromPoint, you could handle <content> and <shadow> specifically
> if you needed to.

Agreed.

> 
> > Now, there is a larger problem here involving touch events. In the
> > implementation of touch events, touchmove does not change target.
> > This means that while the finger is moving on the screen, the same element that
> > received the touchstart event will receive all the touchmoves (and touchend).
> > In this environment, if a finger is placed outside of a ShadowRoot and moved
> > into it, the ShadowRoot will never receive the touchmove event, and cannot call
> > its version of elementFromPoint.
> > 
> > This is a major problem for any polyfilled event systems (like PointerEvents:
> > https://github.com/toolkitchen/PointerEvents).
> 
> The problem with touch is too mind boggling for me. It feels like a separate
> issue. If I understood what you wrote, it seems this problem would happen if
> the touch is moved over an ordinary div, irregardless of whether it has Shadow
> DOM.

The same scenario does occur when using only regular divs, but that problem is
mitigated by dispatching a new event to the element found by EFP. In
ShadowRoots, no shadowed children will be accessible by document EFP, so these
elements cannot even have a new event sent to them in this manual fashion.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 1 October 2012 20:00:12 UTC