When an element in ShadowDOM is touched, the event will be fired from its host element. If the element is in nested ShadowDOM, the element in ShadowDOM will be exposed.
Created attachment 184458 [details] Patch
Comment on attachment 184458 [details] Patch Attachment 184458 [details] did not pass qt-ews (qt): Output: http://queues.webkit.org/results/16072933
Comment on attachment 184458 [details] Patch Attachment 184458 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/16110265
Comment on attachment 184458 [details] Patch Attachment 184458 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/16078921
Comment on attachment 184458 [details] Patch Attachment 184458 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16080895
Created attachment 184631 [details] Patch
Created attachment 184686 [details] Patch
Uploaded the same patch to use cr-linux bot again.
Comment on attachment 184686 [details] Patch What pappens for UA shadows?
Comment on attachment 184686 [details] Patch Attachment 184686 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/16113414 New failing tests: fast/dom/shadow/touch-event.html fast/events/touch/emulate-touch-events.html
(In reply to comment #9) > (From update of attachment 184686 [details]) > What pappens for UA shadows? Basically it should work, since this patch convert the target node into the shadow host. For the complete fix, we have to have the event-retargeting, which will be addressed in Bug 107800. However... it's true that we have to have a test.
Created attachment 184937 [details] Patch
Comment on attachment 184937 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184937&action=review I am not a reviewer but I have a question and some comments inline. > Source/WebCore/ChangeLog:12 > + for backward compatibility. What does this mean for nested Shadow DOM? > LayoutTests/fast/dom/shadow/touch-event.html:2 > +<html><body> You could just write <body> > LayoutTests/fast/dom/shadow/touch-event.html:48 > +container.innerHTML = ""; Use '' for consistency. Maybe container.remove() is neater. > LayoutTests/fast/dom/shadow/touch-event.html:52 > +</body></html> You could omit this line.
(In reply to comment #13) > > What does this mean for nested Shadow DOM? > > > LayoutTests/fast/dom/shadow/touch-event.html:2 > > +<html><body> > > You could just write > > <body> > > > > LayoutTests/fast/dom/shadow/touch-event.html:52 > > +</body></html> > > You could omit this line. WebKit tests traditionally don't do this kind of optimization. It's a matter of taste though.
Comment on attachment 184937 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=184937&action=review >> Source/WebCore/ChangeLog:12 >> + for backward compatibility. > > What does this mean for nested Shadow DOM? We have two options which shadow ancestor nodes we use for nested Shadow DOM. 1) Always use nodes in document tree 2) Use host element in parent tree scope. If we don't use nested ShadowDOM, it's same. If we use nested ShadowDOM, event listener will get different touchTarget. For (1), event listener in ShadowDOM will get wrong touchTarget, while for (2), event listener in document tree scope will get wrong touchTarget. In my opinion, we should prioritize the correctness of document tree scope all time. >> LayoutTests/fast/dom/shadow/touch-event.html:52 >> +</body></html> > > You could omit this line. In my belief, end tag should not be omitted without a strong reason...
Created attachment 185124 [details] Patch
(In reply to comment #15) > (From update of attachment 184937 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=184937&action=review > > >> Source/WebCore/ChangeLog:12 > >> + for backward compatibility. > > > > What does this mean for nested Shadow DOM? > > We have two options which shadow ancestor nodes we use for nested Shadow DOM. > 1) Always use nodes in document tree > 2) Use host element in parent tree scope. > > If we don't use nested ShadowDOM, it's same. > > If we use nested ShadowDOM, event listener will get different touchTarget. For (1), event listener in ShadowDOM will get wrong touchTarget, while for (2), event listener in document tree scope will get wrong touchTarget. > In my opinion, we should prioritize the correctness of document tree scope all time. What does "prioritize the correctness of document tree scope" mean? It means you don’t care what touch targets event handlers in nested Shadow DOM see? That does not seem right.
Comment on attachment 185124 [details] Patch Clearing flags on attachment: 185124 Committed r141054: <http://trac.webkit.org/changeset/141054>
All reviewed patches have been landed. Closing bug.
> What does "prioritize the correctness of document tree scope" mean? It means you don’t care what touch targets event handlers in nested Shadow DOM see? That does not seem right. Did you see my comment and ChangeLog? I chose (1), so touchTarget in ShadowDOM is wrong with this patch. To make it correct in both document tree and shadow tree, event retarget must be implemented. That problem will be addressed in Bug 107800.