104402 - eliminate nsIChromeEventHandler interface from XUL element

Status: RESOLVED FIXED

(Core :: XUL, defect, P3)

Description

[Chris Waterson]

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

Comment 1

[David Hyatt]

Chrome event handler.

Comment 2

[Chris Waterson]

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.

Comment 3

[Chris Waterson]

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.

Comment 4

[Brian Ryner (not reading)]

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.

Comment 5

[Chris Waterson]

shaver?

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Fixed by Bug 363067.