20017 2012-11-20 11:25:29 +0000 [Shadow]: Retargeting relatedTarget algorithm prevents events from be fired if a user creates a MouseEvent manually with a relatedTarget which is same to the target. 2015-05-12 01:36:12 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 28552 28564 1 hayato hayato annevk kenjibaheux public-webapps-bugzilla oldest_to_newest 78523 0 hayato 2012-11-20 11:25:29 +0000 Suppose a user fires an MouseEvent manually as follows: (A) var target = document.getElementById("target"); var newEvent = document.createEvent("MouseEvent"); newEvent.initMouseEvent("mouseover", false, false, window, 0, 10, 10, 10, 10, false, false, false, false, 0, target); target.dispatchEvent(newEvent); In this case, an event should not be fired even at the target node if we follow the (5.2.2): > Event listeners must not be invoked on a node for which the target and relatedTarget are the same. It seems that UA's native MouseEvent never has the relatedTarget which is the same to the target node. But a user generated event can have such a relatedTarget which is the same to the target as I described. For reference, firefox and webkit fires a 'mouseover' event for (A) in the current implementations. How should we resolve this? Option 1): It's okay not to fire an event for (A). I am afraid that this will break the Web. The spec, http://www.w3.org/TR/2001/WD-DOM-Level-3-Events-20010823/events.html, does not tell anything about what we we should do in this case. Option 2): Modify the shadow dom spec so that an event should be fired for (A). 78945 1 dglazkov 2012-11-27 19:22:28 +0000 How about this: state explicitly that the wording in spec only applies to events dispatched by the UA? 78979 2 hayato 2012-11-28 07:40:44 +0000 I am afraid that will mean event relatedTarget retargeting does not happen at all for user generated events? We have to do retargeting for user generated events anyway so that we don't expose nodes in Shadow Tree, don't we? (In reply to comment #1) > How about this: state explicitly that the wording in spec only applies to > events dispatched by the UA? 78981 3 hayato 2012-11-28 07:52:07 +0000 The current WIP patch in WebKit (https://bugs.webkit.org/show_bug.cgi?id=102681) implements the following behavior: If user fires an custom event with a relatedTarget which is same to the target: - Dispatch an event on the ancestor nodes in the shadow tree where the event is originally fired (even though these nodes's target and relatedTarget are same) - Don't dispatch an event for ancestors nodes *beyond* the first shadow boundary. 79718 4 dglazkov 2012-12-08 00:22:57 +0000 I am trying to figure out how to specify this. The whole notion that we're treating synthetic events differently smells wrong. 79719 5 dglazkov 2012-12-08 00:23:31 +0000 Anne, would love to have your insight here. 79747 6 annevk 2012-12-08 09:55:09 +0000 I would start by removing the requirements around "In general". relatedTarget should follow from the algorithm and you do not want two places requiring things about it. Note that relatedTarget can presumably be in a distinct tree as well. In fact, the way it is defined now it can even be an XMLHttpRequest object. So you need to account somehow for these weird cases when doing adjustment. Perhaps just be setting it to the adjusted target? 99377 7 kenjibaheux 2014-01-29 00:44:13 +0000 (Memo) This is affecting the following test: https://github.com/w3c/web-platform-tests/blob/master/shadow-dom/events/event-retargeting/test-002.html 119775 8 hayato 2015-04-22 22:54:46 +0000 This topic looks an old (and minor?) issue, the issue still remains, I think. My opinion doesn't change. I'm not sure how we should do. The speccing comment #3 is reasonable? I'm not confident. 119838 9 annevk 2015-04-23 18:41:42 +0000 The right approach here is to only do the relatedTarget check when the event is trusted. So if the event is trusted and the relatedTarget check returns true, pick a limited path at dispatch time. 119851 10 annevk 2015-04-23 20:58:06 +0000 *** Bug 22793 has been marked as a duplicate of this bug. *** 120249 11 hayato 2015-05-11 04:58:42 +0000 I'm fine with comment #9. Unless there is no objection, let me spec it. I'm assuming that an untrusted event which has a relatedTarget originated the component wouldn't be *noisy* for the users of the components. I guess the number of such an event is limited. 120254 12 hayato 2015-05-12 01:36:12 +0000 Done at https://github.com/w3c/webcomponents/commit/58c8aec79039f403157a18c05b0125c134275e8a.