Bug 16487 - EventTarget constructor
Summary: EventTarget constructor
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
Depends on: 18780
  Show dependency treegraph
Reported: 2012-03-23 07:53 UTC by Anne
Modified: 2014-02-13 11:41 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Anne 2012-03-23 07:53:12 UTC
Define a way to construct an EventTarget with a modifiable parent chain. Suggestion from smaug:

interface EventReceiver : EventTarget {
  attribute EventTarget parent;
Comment 1 Anne 2012-10-10 16:24:11 UTC
How were we going to deal with cycles here?
Comment 2 Anne 2012-12-13 10:59:19 UTC
Modifying the event parent seems problematic. If we instead pass the parent to the constructor there will never be a problem as far as I can tell.
Comment 3 Olli Pettay 2012-12-13 13:08:30 UTC
Why is modifying the parent problematic?
Nodes can be moved around and that isn't problematic.
Comment 4 Olli Pettay 2012-12-13 13:09:31 UTC
Though, I'm not sure we need to support modifying .parent.
Comment 5 Anne 2012-12-14 11:00:07 UTC
The problem is that when you do event dispatch you need to compute the ancestor chain. If parent becomes settable, A can be a parent of B and B can be a parent of A, which thus far has been impossible and would require the introduction of cycle detection.
Comment 6 Olli Pettay 2012-12-14 13:27:26 UTC
Of course there would have to be cycle detection. Nodes have it too.
Comment 7 Anne 2013-02-11 21:06:16 UTC
My suggestion is that we make it more explicit in the specification that EventTarget has an associated "event parent" concept (we need that anyway). We then allow that concept to be set through the constructor:

[Constructor(optional EventTarget = null)]
interface EventTarget ...

If we want we could expose that concept on the interface, but I don't think we need to do that right away. For nodes this is already covered by parentNode, for custom EventTarget objects this could be manually managed.
Comment 8 Anne 2014-02-13 11:41:21 UTC
This does not seem high priority given the other things we have going on. JavaScript will prolly provide this in due course.