This will make bug 659350 much simpler. Patches coming up.

Oh, and the point is that this can land before the rest of bug 659350, thus giving us separate regression ranges in the unlikely case that the changes in this bug cause a regression.

Try run at http://tbpl.mozilla.org/?tree=Try&rev=07d05b5af364

Comment on attachment 549549 [details] [diff] [review] part 3. Expand the event list to contain more information than just the name and move all the information from the tables in nsContentUtils to it. >@@ -157,16 +157,17 @@ enum EventNameType { > EventNameType_None = 0x0000, > EventNameType_HTML = 0x0001, > EventNameType_XUL = 0x0002, > EventNameType_SVGGraphic = 0x0004, // svg graphic elements > EventNameType_SVGSVG = 0x0008, // the svg element > EventNameType_SMIL = 0x0016, // smil elements > > EventNameType_HTMLXUL = 0x0003, >+ EventNameType_HTMLXULSVGSVG = 0x000B, Do you actually use this for something? Either remove or use it somewhere >+// XXXbz durationchange, emptied, ended, loadeddata, loadedmetadata, >+// loadstart, pause, play, playing, progress, ratechange, seeked, >+// stalled, suspend, timeupdate, volumechange, waiting used to be >+// conditioned on MOZ_MEDIA. What should we do with them? Since the >+// IDL is unconditional, my instinct is to just make them >+// unconditional. I'm ok with that change. >+// Not supported yet >+// EVENT(mousewheel) And I assume we're not going to support that, but wheel event >+// Not supported yet >+// EVENT(show) This is coming real soon, I hope :) >+EVENT(timeupdate, NS_TIMEUPDATE, EventNameType_HTML, NS_EVENT_NULL) Please use the same style as elsewhere > // Gecko-specific extensions that apply to elements I doubt copy/cut/paste are gecko specific, but the clipboard spec just happens to be quite early draft. >+// XUL specific events This is a bit wrong. We just happen to support onfoo in XUL, but compositionstart/end and text are dispatched in HTML too. And the list continues to SVG without a break. >+NON_IDL_EVENT(transitionend, >+ NS_TRANSITION_END, >+ EventNameType_None, >+ NS_TRANSITION_EVENT) >+NON_IDL_EVENT(animationstart, >+ NS_ANIMATION_START, >+ EventNameType_None, >+ NS_ANIMATION_EVENT) >+NON_IDL_EVENT(animationend, >+ NS_ANIMATION_END, >+ EventNameType_None, >+ NS_ANIMATION_EVENT) >+NON_IDL_EVENT(animationiteration, >+ NS_ANIMATION_ITERATION, >+ EventNameType_None, >+ NS_ANIMATION_EVENT) I wonder what other browsers do with this. Does the CSS spec anything about onfoo listener. Could you file a followup to figure that out.

> Do you actually use this for something? I was going to (by just listing the part after "EventNameType_" in the third macro argument), but then changed my mind. Will remove that line. > I'm ok with that change. Er, yes. I'll take that comment out. > And I assume we're not going to support that, but wheel event Then we should consider filing a spec bug on HTML5, which requires support for onmousewheel. > Please use the same style as elsewhere Er, yes. Fixed. > This is a bit wrong. We just happen to support onfoo in XUL, but > compositionstart/end and text are dispatched in HTML too. > And the list continues to SVG without a break. I think I just copied the comments we used to have... I'll fix them to make a bit more sense. > Does the CSS spec anything about onfoo listener. It does not. WebKit does not seem to have on* properties for the transition and animation events. In any case, filed bug 677131.

> Then we should consider filing a spec bug on HTML5 In the meantime, I changed the comment to talk about "wheel" support instead of mousewheel.

http://hg.mozilla.org/integration/mozilla-inbound/rev/e2f2476215cd http://hg.mozilla.org/integration/mozilla-inbound/rev/28a12583603b http://hg.mozilla.org/integration/mozilla-inbound/rev/840e9e5c5059

http://hg.mozilla.org/mozilla-central/rev/e2f2476215cd http://hg.mozilla.org/mozilla-central/rev/28a12583603b http://hg.mozilla.org/mozilla-central/rev/840e9e5c5059