Bug 68791 - [meta] Remove init*Event methods
: [meta] Remove init*Event methods
Status: NEW
Product: WebKit
Classification: Unclassified
Component: HTML DOM
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: Nobody
:
Depends on: 71338 71340 71344 71374 71636 71687 71689 71691 71698 71701
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-25 23:56 PDT by Anne van Kesteren
Modified: 2011-12-25 21:58 PST (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anne van Kesteren 2011-09-25 23:56:23 PDT
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 Adam Barth 2011-09-26 11:45:18 PDT
Is the idea here that no one has shipped these APIs yet so author aren't using them?
Comment 2 Dimitri Glazkov (Google) 2011-09-26 11:47:43 PDT
We can't really remove them, they are already used widely in the wild :(
Comment 5 Dimitri Glazkov (Google) 2011-09-26 12:06:36 PDT
(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 Ian 'Hixie' Hickson 2011-09-26 13:09:05 PDT
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 Dimitri Glazkov (Google) 2011-09-26 13:27:27 PDT
(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 Sam Weinig 2011-09-26 20:10:46 PDT
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 Sam Weinig 2011-09-26 20:14:12 PDT
CloseEvent?  MediaSteamEvent? WebGLContextEvent? PopStateEvent? PageTransisionEvent? The webkit version of MessageEvent?
Comment 10 Dominic Cooney 2011-11-01 16:38:13 PDT
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 Dominic Cooney 2011-11-01 18:16:35 PDT
Should these events be removed from EventFactory.in at the same time? createEvent('ProgressEvent') does not seem useful without initProgressEvent, for example.
Comment 12 Adam Barth 2011-11-02 10:59:13 PDT
> 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 Dominic Cooney 2011-11-02 11:29:28 PDT
(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 Dominic Cooney 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 Dominic Cooney 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>