This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20017 - [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.
Summary: [Shadow]: Retargeting relatedTarget algorithm prevents events from be fired i...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 22793 (view as bug list)
Depends on:
Blocks: 28552 28564
  Show dependency tree / graph
 
Reported: 2012-11-20 11:25 UTC by Hayato Ito
Modified: 2015-05-12 01:36 UTC (History)
2 users (show)

See Also:

Attachments

Description Hayato Ito 2012-11-20 11:25:29 UTC 
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).
Comment 1 Dimitri Glazkov 2012-11-27 19:22:28 UTC 
How about this: state explicitly that the wording in spec only applies to events dispatched by the UA?
Comment 2 Hayato Ito 2012-11-28 07:40:44 UTC 
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?
Comment 3 Hayato Ito 2012-11-28 07:52:07 UTC 
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.
Comment 4 Dimitri Glazkov 2012-12-08 00:22:57 UTC 
I am trying to figure out how to specify this. The whole notion that we're treating synthetic events differently smells wrong.
Comment 5 Dimitri Glazkov 2012-12-08 00:23:31 UTC 
Anne, would love to have your insight here.
Comment 6 Anne 2012-12-08 09:55:09 UTC 
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?
Comment 7 Kenji Baheux 2014-01-29 00:44:13 UTC 
(Memo)
This is affecting the following test:
    https://github.com/w3c/web-platform-tests/blob/master/shadow-dom/events/event-retargeting/test-002.html
Comment 8 Hayato Ito 2015-04-22 22:54:46 UTC 
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.
Comment 9 Anne 2015-04-23 18:41:42 UTC 
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.
Comment 10 Anne 2015-04-23 20:58:06 UTC 
*** Bug 22793 has been marked as a duplicate of this bug. ***
Comment 11 Hayato Ito 2015-05-11 04:58:42 UTC 
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.