Bug 68791 - [meta] Remove init*Event methods
: [meta] Remove init*Event methods
Status: NEW
: WebKit
HTML DOM
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
:
:
: 71338 71340 71344 71374 71636 71687 71689 71691 71698 71701
:
  Show dependency treegraph
 
Reported: 2011-09-25 23:56 PST by
Modified: 2011-12-25 21:58 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2011-09-25 23:56:23 PST
Now we have event constructors the init*Event methods on recently introduced Event interfaces can be removed. It is no longer correct to support them for CustomEvent, ErrorEvent, ProgressEvent, etc.
------- Comment #1 From 2011-09-26 11:45:18 PST -------
Is the idea here that no one has shipped these APIs yet so author aren't using them?
------- Comment #2 From 2011-09-26 11:47:43 PST -------
We can't really remove them, they are already used widely in the wild :(
------- Comment #4 From 2011-09-26 12:04:03 PST -------
This search comes up clean:

http://codesearch.google.com/codesearch#search/&q=init(Error%7CProgress)Event%20lang:js&type=cs
------- Comment #5 From 2011-09-26 12:06:36 PST -------
(In reply to comment #4)
> This search comes up clean:
> 
> http://codesearch.google.com/codesearch#search/&q=init(Error%7CProgress)Event%20lang:js&type=cs

We can certainly try to kill them :)
------- Comment #6 From 2011-09-26 13:09:05 PST -------
Obviously the ancient ones like initMouseEvent aren't going anywhere.

But many of the new ones haven't even shipped in multiple browsers yet. Those are the ones that should go, e.g. almost all the ones in the HTML spec.
------- Comment #7 From 2011-09-26 13:27:27 PST -------
(In reply to comment #6)
> Obviously the ancient ones like initMouseEvent aren't going anywhere.
> 
> But many of the new ones haven't even shipped in multiple browsers yet. Those are the ones that should go, e.g. almost all the ones in the HTML spec.

SGTM.
------- Comment #8 From 2011-09-26 20:10:46 PST -------
Purging initErrorEvent and initProgressEvent sounds great (probably can't with Custom, since I think some YUI stuff use it).  There are probably some other ones we can kill as well (perhaps some of the ones we have added in the last few months, Composition?)
------- Comment #9 From 2011-09-26 20:14:12 PST -------
CloseEvent?  MediaSteamEvent? WebGLContextEvent? PopStateEvent? PageTransisionEvent? The webkit version of MessageEvent?
------- Comment #10 From 2011-11-01 16:38:13 PST -------
Assuming we want to remove separate init*Event methods in separate patches, to make it easier to roll individual methods back in if it turns out they are used in the wild.
------- Comment #11 From 2011-11-01 18:16:35 PST -------
Should these events be removed from EventFactory.in at the same time? createEvent('ProgressEvent') does not seem useful without initProgressEvent, for example.
------- Comment #12 From 2011-11-02 10:59:13 PST -------
> Should these events be removed from EventFactory.in at the same time? createEvent('ProgressEvent') does not seem useful without initProgressEvent, for example.

That will effect the JS wrapper selection as well.  When the IDL says Event, the bindings actually return a wrapper for the actual type of the Event.  EventFactory.in provides an enumeration of all the event interfaces.

IMHO, there isn't anything to be gained by preventing these objects from being created by createEvent.
------- Comment #13 From 2011-11-02 11:29:28 PST -------
(In reply to comment #12)
> That will effect the JS wrapper selection as well.  When the IDL says Event, the bindings actually return a wrapper for the actual type of the Event.  EventFactory.in provides an enumeration of all the event interfaces.
> 
> IMHO, there isn't anything to be gained by preventing these objects from being created by createEvent.

Got it. I will leave createEvent alone.
------- Comment #14 From 2011-11-06 16:05:56 PST -------
I have taken a look at all of the events in WebKit, the relevant specs, and whether the events are used (using Code Search.) Here is what I think we should do. For convenience I am just going to mention the event interface name, but I mean init*Event:

These are ones we already removed:

ErrorEvent (bug 71338), MediaStreamEvent (bug 71344), TrackEvent (never implemented)

I think we can remove these:

BeforeLoadEvent (bug 71636), CloseEvent (bug 71374), OverflowEvent, PageTransitionEvent, PopStateEvent, ProgressEvent (bug 71340), WebKitAnimationEvent, WebKitTransitionEvent

We *might* be able to remove these:

StorageEvent—used by Unhosted; HashChangeEvent—used by Ample SDK.

I think we can remove these, but we need to file bugs against the specs to get the specs updated:

AudioProcessingEvent, DeviceMotionEvent, DeviceOrientationEvent, WebGLContextEvent

And for completeness, these are the untouchables—we can’t remove these, it seems hordes of people use them:

CompositionEvent, CustomEvent (YUI), Event, KeyboardEvent, MessageEvent, MouseEvent, MutationEvent, TextEvent, TouchEvent, UIEvent, WheelEvent
------- Comment #15 From 2011-12-25 21:58:38 PST -------
On more careful inspection I am not sure whether YUI uses initCustomEvent. It has a method of its own, initCustomEvent*s*, that is unrelated but shows up in casual searches.

However initCustomEvent is used in smaller frameworks such as Ample, JSDOM and "XBL" <http://codesearch.google.com/#search/&q=initCustomEvent%5B%5Es%5D%20lang:js&type=cs>