Closed
Bug 329112
Opened 20 years ago
Closed 20 years ago
Move GetListenerManager from nsIContent to nsINode
Categories
(Core :: DOM: Events, defect)
Core
DOM: Events
Tracking
()
RESOLVED
FIXED
People
(Reporter: smaug, Unassigned)
References
Details
Move GetListenerManager from nsIContent to nsINode
Do something to nsIDOMEventReceiver::GetListenerManager too?
| Reporter | ||
Comment 1•20 years ago
|
||
I don't especially like to have one method to implement something from two
interfaces but in this case I could easily remove nsINode::GetEventListenerManager
(which I added in bug 234455) and move nsIContent::GetListenerManager to nsINode.
This would mean that nsDocument::GetListenerManager is the implementation of nsINode::GetListenerManager and nsIDOMEventReceiver::GetListenerManager.
Any objections? Or any better suggestions?
Comment 2•20 years ago
|
||
Or we could move GetListenerManager() off nsIDOMEventReceiver altogether and put it on nsINode and nsPIDOMWindow?
Or will that break consumers?
What would really be great is if we had the event stuff on the "main" chain of node/window interfaces (eg if nsIDOMEventReceiver didn't inherit from nsIDOMEventTarget and instead inherited from nsIDOMGCParticipant or something)...
| Reporter | ||
Comment 3•20 years ago
|
||
This got fixed in bug 334075.
> What would really be great is if we had the event stuff on the "main" chain of
> node/window interfaces (eg if nsIDOMEventReceiver didn't inherit from
> nsIDOMEventTarget and instead inherited from nsIDOMGCParticipant or
> something)...
For this something else is needed...
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Would it be possible to remove GetListenerManager from nsIDOMEventReceiver? I ended up having to make the version on nsINode use NS_IMETHOD since nsDocument got its knickers in a knot if it had to implement two methods with the same signature but with different calling conventions.
| Reporter | ||
Comment 5•20 years ago
|
||
nsGlobalWindow and nsWindowRoot are nsIDOMEventReceivers and there
must be a way to get their listenermanager somehow...
You need to log in
before you can comment on or make changes to this bug.
Description
•