21404 2013-03-26 18:56:14 +0000 [Shadow]: 5.5 Event Dispatch references incorrect steps of event dispatching algorithm 2013-05-07 22:11:32 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 18428 21499 1 dfreedm dglazkov bugs hayato mrbkap sorvell wchen public-webapps-bugzilla oldest_to_newest 85032 0 dfreedm 2013-03-26 18:56:14 +0000 In section 5.5, where the event dispatching algorithm detailed in http://www.w3.org/TR/domcore/#dispatching-events is referenced, the capturing phase should reference step 6 of the event dispatching algorithm, and the bubbling phase should reference step 9. As currently written, bubbling events processing through a Shadow Root would be processed in a capture order. 85160 1 dglazkov 2013-03-29 20:14:11 +0000 Olli, wanted to check with you on this. It makes good sense to me. Here's a really good example that Daniel built: http://jsfiddle.net/dfreedm/EMgtb/ 85194 2 hayato 2013-04-01 01:37:05 +0000 Maybe we should revert this change in WebKit side: https://bugs.webkit.org/show_bug.cgi?id=112214 I think the original behavior in WebKit is what we want. What we have to do is to update the spec so that the spec matches the WebKit's original behavior. 85195 3 dglazkov 2013-04-01 02:35:50 +0000 (In reply to comment #2) > Maybe we should revert this change in WebKit side: > > https://bugs.webkit.org/show_bug.cgi?id=112214 Okay. 85196 4 hayato 2013-04-01 02:37:02 +0000 To continue further, let me confirm 'the desired behavior' at first. Given the event path, from Node A (top-most) to Node G (target, inner-most), where C and D are shadow hosts and G is the target, an event dispatching order in the current WebKit implementaion is: (T: AT_TARGET, C: CAPTURING, B: BUBBLING) For bubbling events: A 1 (C) 11 (B) B 2 (C) 10 (B) C (SH) 3 (T) D 4 (C) 9 (B) E (SH) 5 (T) F 6 (C) 8 (B) G (Target) 7 (T) For non-bubbling events: A 1 (C) B 2 (C) C (SH) 3 (T) D 4 (C) E (SH) 5 (T) F 6 (C) G (Target) 7 (T) Are we changing this behavior? 85197 5 hayato 2013-04-01 02:42:01 +0000 Let me ignore my comment #2. Could you see comment #4? (In reply to comment #3) > (In reply to comment #2) > > Maybe we should revert this change in WebKit side: > > > > https://bugs.webkit.org/show_bug.cgi?id=112214 > > Okay. 85199 6 dglazkov 2013-04-01 03:08:19 +0000 (In reply to comment #5) I think what Daniel wants is: A 1 (C) B 2 (C) C (SH) 7 (T) D 3 (C) E (SH) 6 (T) F 4 (C) G (Target) 5 (T) Effectively, with Shadow DOM, AT_TARGET phase: 1) mimics bubbling if event is non-bubbling, or 2) is combined with bubbling otherwise. Does this make any sense? Does this seem like a good idea? :) 85200 7 hayato 2013-04-01 03:14:13 +0000 I don't have a strong opinion to either idea. For me, the original one looks natural one. I'd like to know the reason and use cases for changing the behavior. (In reply to comment #6) > (In reply to comment #5) > > I think what Daniel wants is: > > A 1 (C) > B 2 (C) > C (SH) 7 (T) > D 3 (C) > E (SH) 6 (T) > F 4 (C) > G (Target) 5 (T) > > Effectively, with Shadow DOM, AT_TARGET phase: > 1) mimics bubbling if event is non-bubbling, or > 2) is combined with bubbling otherwise. > > Does this make any sense? Does this seem like a good idea? :) 85201 8 hayato 2013-04-01 03:25:30 +0000 (In reply to comment #6) > Effectively, with Shadow DOM, AT_TARGET phase: > 1) mimics bubbling if event is non-bubbling, or > 2) is combined with bubbling otherwise. > > Does this make any sense? Does this seem like a good idea? :) I guess that since element.addEventListener's third parameter, useCapture, is 'false' in default, people is likely to have a mental model of 'event listernes are called from inner to outer'. That might support the idea of 'minicing bubbling events' for AT_TARGET phase. 85202 9 dglazkov 2013-04-01 03:33:15 +0000 (In reply to comment #8) > I guess that since element.addEventListener's third parameter, useCapture, > is 'false' in default, people is likely to have a mental model of 'event > listernes are called from inner to outer'. > That might support the idea of 'minicing bubbling events' for AT_TARGET > phase. Right. Most of the time this parameter is false (very few use capture), so the order of events looks whacky: first listener is fired on the host that's farthest from the target. 85204 10 hayato 2013-04-01 03:44:35 +0000 (In reply to comment #9) > (In reply to comment #8) > > I guess that since element.addEventListener's third parameter, useCapture, > > is 'false' in default, people is likely to have a mental model of 'event > > listernes are called from inner to outer'. > > That might support the idea of 'minicing bubbling events' for AT_TARGET > > phase. > > Right. Most of the time this parameter is false (very few use capture), so > the order of events looks whacky: first listener is fired on the host that's > farthest from the target. Okay. Agreed. Let's change the order. For the record, the new order should be: For bubbling events: A 1 (C) 11 (B) B 2 (C) 10 (B) C (SH) 9 (T) D 3 (C) 8 (B) E (SH) 7 (T) F 4 (C) 6 (B) G (Target) 5 (T) For non-bubbling events: A 1 (C) B 2 (C) C (SH) 7 (T) D 3 (C) E (SH) 6 (T) F 4 (C) G (Target) 5 (T) Does this sound good? 85234 11 hayato 2013-04-01 04:09:22 +0000 I have to address one more issue: How to handle event.cancelBubble in the new event order? For example, if an event lister on Node E sets event.cancelBubble to true on #7, what should be done for (#8 - #11)? My idea is: - Event listeners on #9 should be called with AT_TARGET phase even though. - Event listeners on (#8, #10, #11) should not be called with BUBBLING phase. > For bubbling events: > > A 1 (C) 11 (B) > B 2 (C) 10 (B) > C (SH) 9 (T) > D 3 (C) 8 (B) > E (SH) 7 (T) > F 4 (C) 6 (B) > G (Target) 5 (T) 85239 12 hayato 2013-04-01 06:19:05 +0000 For reference, I've uploaded a patch in implementation side: https://bugs.webkit.org/show_bug.cgi?id=113676 85257 13 dglazkov 2013-04-01 15:51:32 +0000 (In reply to comment #11) > I have to address one more issue: > How to handle event.cancelBubble in the new event order? > > For example, if an event lister on Node E sets event.cancelBubble to true on > #7, what should be done for (#8 - #11)? > > My idea is: > - Event listeners on #9 should be called with AT_TARGET phase even though. > - Event listeners on (#8, #10, #11) should not be called with BUBBLING > phase. I think this is reasonable. 87384 14 dglazkov 2013-05-07 22:11:32 +0000 https://dvcs.w3.org/hg/webcomponents/rev/1150e6c009d3 Please let me know if I messed things up. Also, adding William+Blake to keep such changes on their radars.