790263 - Don't use nsIDOMEventListener for onfoo attributes, particularly on web-facing interfaces

Status: RESOLVED DUPLICATE of bug 899322

(Core :: DOM: Core & HTML, defect)

Description

[Justin Lebar (not reading bugmail)]

bz says in bug 779500 comment 98 that

  attribute jsval onfoo;

and

  attribute nsIDOMEventListener onfoo;

are different from a webpage's point of view.  In particular,

  onfoo = { dispatchEvent: function() { ... } };

will work only if onfoo is an nsIDOMEventListener.

Since most of our onfoo properties are jsvals, we should use jsvals elsewhere, for consistency.

$ git ls-files | grep 'idl$' | xargs grep 'attribute\s\+nsIDOMEventListener'
b2g/components/b2g.idl:  attribute nsIDOMEventListener onfocuschange;
dom/interfaces/apps/nsIDOMApplicationRegistry.idl:  attribute nsIDOMEventListener onprogress;
dom/interfaces/apps/nsIDOMApplicationRegistry.idl:  attribute nsIDOMEventListener oninstall;
dom/interfaces/apps/nsIDOMApplicationRegistry.idl:  attribute nsIDOMEventListener onuninstall;
dom/interfaces/contacts/nsIDOMContactManager.idl:  attribute nsIDOMEventListener oncontactchange;
dom/interfaces/settings/nsIDOMSettingsManager.idl:  attribute nsIDOMEventListener onsettingchange;
dom/wifi/nsIWifi.idl:    attribute nsIDOMEventListener onstatuschange;
dom/wifi/nsIWifi.idl:    attribute nsIDOMEventListener connectionInfoUpdate;
dom/wifi/nsIWifi.idl:    attribute nsIDOMEventListener onenabled;
dom/wifi/nsIWifi.idl:    attribute nsIDOMEventListener ondisabled;

We might as well change all of these interfaces, if we can, but only the ones that are exposed to the DOM are worth worrying about.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note that Kyle recently fixed a bunch of this stuff in bug 687332, but then various webapi stuff got added between him writing the patch and getting review...

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I fixed everything that inherits from nsDOMEventTargetHelper (and changed it so that you can't make this mistake with nsDOMEventTargetHelper, at least if you use the macros).  These all appear to be implemented in JS, which means that their event behavior is all fucked up already.

Comment 3

[Mike Hoye [:mhoye]]

This bug is looking for a mentor. Kyle?

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't think this is an issue now that we have WebIDL bindings. bz?

Comment 5

[Boris Zbarsky [:bzbarsky]]

As of today, the only remaining on* things that have nsIDOMEventListener are on nsIDOMApplicationRegistry.

I'm told there's a plan to convert that to WebIDL, which will automatically fix this bug.