68791 2011-09-25 23:56:23 -0700 [meta] Remove init*Event methods 2017-08-04 06:04:32 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 71338 71340 71344 71374 71636 71687 71689 71691 71698 71701 1 annevk webkit-unassigned abarth ap cmarcelo dglazkov dominicc haraken haraken ian laszlo.gombos luchellesheldon sam oldest_to_newest 472984 0 annevk 2011-09-25 23:56:23 -0700 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. 473250 1 abarth 2011-09-26 11:45:18 -0700 Is the idea here that no one has shipped these APIs yet so author aren't using them? 473253 2 dglazkov 2011-09-26 11:47:43 -0700 We can't really remove them, they are already used widely in the wild :( 473255 3 dglazkov 2011-09-26 11:49:17 -0700 http://codesearch.google.com/codesearch#search/&q=init(Custom%7CError%7CMouse%7CProgress)Event%20lang:js&type=cs 473275 4 abarth 2011-09-26 12:04:03 -0700 This search comes up clean: http://codesearch.google.com/codesearch#search/&q=init(Error%7CProgress)Event%20lang:js&type=cs 473277 5 dglazkov 2011-09-26 12:06:36 -0700 (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 :) 473333 6 ian 2011-09-26 13:09:05 -0700 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. 473339 7 dglazkov 2011-09-26 13:27:27 -0700 (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. 473654 8 sam 2011-09-26 20:10:46 -0700 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?) 473655 9 sam 2011-09-26 20:14:12 -0700 CloseEvent? MediaSteamEvent? WebGLContextEvent? PopStateEvent? PageTransisionEvent? The webkit version of MessageEvent? 494293 10 dominicc 2011-11-01 16:38:13 -0700 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. 494383 11 dominicc 2011-11-01 18:16:35 -0700 Should these events be removed from EventFactory.in at the same time? createEvent('ProgressEvent') does not seem useful without initProgressEvent, for example. 494736 12 abarth 2011-11-02 10:59:13 -0700 > 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. 494757 13 dominicc 2011-11-02 11:29:28 -0700 (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. 496910 14 dominicc 2011-11-06 16:05:56 -0800 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 527139 15 dominicc 2011-12-25 21:58:38 -0800 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> 1335226 16 annevk 2017-08-04 06:04:32 -0700 Fixed per dependencies.