Chris Waterson Reporter
	Description • 23 years ago

hyatt, was this the interface we wanted to nix from XUL element? Or was it
nsIChromeEventHandler?

	David Hyatt
	Comment 1 • 23 years ago

Chrome event handler.

	Chris Waterson Reporter
	Comment 2 • 23 years ago

So, ahh, hrm. I'm going to need a little guidance here. Could I simply eliminate
the nsIChromeEventHandler interface altogether, and use the nsIContent interface
(calling HandleDOMEvent directly)? Oops, no nsWindowRoot stuffs that idea.
Should we make a subclass of nsXULElement that implements this for <browser>'s?
(I suppose that's what this is for.) Anyway, vend me a clue.

Also, looking at this makes me sad that we added nsIScriptEventHandlerOwner. I
wonder if that functionality could've been rolled into another interface (like
nsIScriptObjectOwner). Finally, it's too bad that nsIDOMEventReceiver and
nsIDOMEventTarget have to be separate interfaces, since I bet all elements can
be targets. Maybe we did this because documents can be event targets, too (but
documents aren't elements, even though the look sort of like elements). Ah to be
back in the salad days when ifaces were loose and free.

	Chris Waterson Reporter
	Comment 3 • 23 years ago

bryner, here's a footprint win that would be splendid to get in. I have no idea
how hyatt intended to do this. If you're not interested, send it back to me and
I'll deal with it after sabbatical.

	Brian Ryner (not reading)
	Comment 4 • 23 years ago

I'm interested, but I talked this over with hyatt and this is definitely
non-trivial.  I'm loaded up with XBL form control stuff at the moment, so I'm
not going to have time to get to this anytime soon.  Back to you, but I'll ping
you about this if I end up having time to work on it.

	Chris Waterson Reporter
	Comment 5 • 23 years ago

shaver?

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 21 years ago

sicking, weren't we just talking about this?  ;)

	Olli Pettay [:smaug][bugs@pettay.fi] Assignee
	Comment 7 • 18 years ago

Fixed by Bug 363067.