Create a header listing events we know about so we can preprocess it in various ways

RESOLVED FIXED in mozilla8

Status

()

Core
DOM: Events
P1
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

Trunk
mozilla8
x86
Mac OS X
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

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.
Created attachment 549547 [details] [diff] [review]
part 1.  Create a header that defines the various event names in HTML5.
Attachment #549547 - Flags: review?(Olli.Pettay)
Created attachment 549548 [details] [diff] [review]
part 2.  Add some events that we implement that aren't in the spec to the event list, and convert the long lists of event stuff in classinfo to using the canonical event list.
Attachment #549548 - Flags: review?(Olli.Pettay)
Created 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.
Attachment #549549 - Flags: review?(Olli.Pettay)
Try run at http://tbpl.mozilla.org/?tree=Try&rev=07d05b5af364

Updated

6 years ago
Attachment #549547 - Flags: review?(Olli.Pettay) → review+

Updated

6 years ago
Attachment #549548 - Flags: review?(Olli.Pettay) → review+

Comment 6

6 years ago
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.
Attachment #549549 - Flags: review?(Olli.Pettay) → review+
> 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
Flags: in-testsuite-
Target Milestone: --- → mozilla8
http://hg.mozilla.org/mozilla-central/rev/e2f2476215cd
http://hg.mozilla.org/mozilla-central/rev/28a12583603b
http://hg.mozilla.org/mozilla-central/rev/840e9e5c5059
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.