After bug 363067, nsIDOMEventReceiver could be merged to nsPIDOMEventTarget.
Actually, nsIDOMEventReceiver can be just removed and use nsIEventListenerManager when really needed.
WIP patch containing also bug 363067 is here http://www.cs.helsinki.fi/u/pettay/moztests/events/remove_nsidomeventreceiver.diff
should remove now all uses of nsIDOMEventReceiver.
And it even compiles (ff, tb, sm) :)
Waiting for bug 363067.
Created attachment 262273 [details] [diff] [review]
Comment on attachment 262273 [details] [diff] [review]
- In content/xbl/public/nsIXBLService.h:
- NS_IMETHOD AttachGlobalKeyHandler(nsIDOMEventReceiver* aElement)=0;
+ NS_IMETHOD AttachGlobalKeyHandler(nsPIDOMEventTarget* aTarget)=0;
Since you're changing this "interface", you should bump the IID here (even if it's not in IDL). Same for nsPIDOMEventTarget.
- In embedding/browser/gtk/src/EmbedPrivate.h:
- // our event receiver
- nsCOMPtr<nsIDOMEventReceiver> mEventReceiver;
+ nsCOMPtr<nsPIDOMEventTarget> mEventTarget;
Add a space to make member names line up again.
r+sr=jst with that.
I'll check this in during next weekend, when there aren't too many
bah, I just checked this in. Hoping not to see to much red in tboxes.
backed out. some chrome and mochitests failed and couldn't immediately see where to problem is.
Created attachment 264731 [details] [diff] [review]
nsIDOMEventTarget occurs still few times in the tree, for example in
some comments. I'll post a small patch to remove those.
Created attachment 264801 [details] [diff] [review]
Things which aren't usually (or ever) compiled.
The strange looking part is nsWindowRoot, but those macros don't
actually use the second parameter currently.
Comment on attachment 264801 [details] [diff] [review]