Add more init*Event()?

[zcorpan]

See whatwg/dom@9e3ce67

For these event interfaces we should check if they need init*Event methods. Just supporting them in createEvent is pretty pointless if it still throws for the init*Event call...

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4067

WebKit:

log: These init*Event are defined:
log: initCompositionEvent
log: initCustomEvent
log: initEvent
log: initHashChangeEvent
log: initKeyboardEvent
log: initMessageEvent
log: initMouseEvent
log: initStorageEvent
log: initTextEvent
log: initUIEvent
log: 
log: Exceptions for createEvent(...):
log: DeviceMotionEvent
log: DeviceOrientationEvent
log: DragEvent
log: SVGEvent
log: TouchEvent

Chromium:

log: These init*Event are defined:
log: initCompositionEvent
log: initCustomEvent
log: initDeviceMotionEvent
log: initDeviceOrientationEvent
log: initEvent
log: initKeyboardEvent
log: initMessageEvent
log: initMouseEvent
log: initStorageEvent
log: initTextEvent
log: initUIEvent
log: 
log: Exceptions for createEvent(...):
log: SVGEvent
log: TouchEvent

Gecko:

log: These init*Event are defined:
log: initCompositionEvent
log: initCustomEvent
log: initDeviceMotionEvent
log: initDeviceOrientationEvent
log: initDragEvent
log: initEvent
log: initHashChangeEvent
log: initMessageEvent
log: initMouseEvent
log: initStorageEvent
log: initUIEvent
log: 
log: Exceptions for createEvent(...):
log: AnimationEvent
log: CloseEvent
log: ErrorEvent
log: FocusEvent
log: IDBVersionChangeEvent
log: PageTransitionEvent
log: ProgressEvent
log: TouchEvent
log: TrackEvent
log: TransitionEvent
log: WebGLContextEvent
log: WheelEvent

Edge:

log: These init*Event are defined:
log: initAnimationEvent
log: initCloseEvent
log: initCompositionEvent
log: initCustomEvent
log: initDeviceMotionEvent
log: initDeviceOrientationEvent
log: initDragEvent
log: initErrorEvent
log: initEvent
log: initFocusEvent
log: initKeyboardEvent
log: initMessageEvent
log: initMouseEvent
log: initPopStateEvent
log: initProgressEvent
log: initStorageEvent
log: initTextEvent
log: initTransitionEvent
log: initUIEvent
log: initWheelEvent
log: 
log: Exceptions for createEvent(...):
log: BeforeUnloadEvent
log: SVGEvent
log: SVGZoomEvent
log: TouchEvent

[annevk]

createEvent should not really be taken as guidance though. It's a legacy method and we only support there what we need to for compatibility.

[zcorpan]

Right. For compatibility with Web pages that use them, those pages will probably still be broken if the relevant init*Event method is not defined. We went through this in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25907 :-)

[zcorpan]

cc @ayg

[domenic]

I edited the OP to include the Edge results.

[ayg]

This comment may be of interest:

  // XXXkhuey Chrome supports popstateevent here, even though it provides no
  // initPopStateEvent method.  This is nuts ... but copying it is unlikely to
  // break the web.

http://hg.mozilla.org/mozilla-central/file/1da1937a9e03/dom/events/EventDispatcher.cpp#l915

Anyway, though, adding init*Event methods that most browsers support makes sense too, yes. Result of concatenation of the four lists followed by sort | uniq -c | sort -nr:

      4 log: initUIEvent
      4 log: initStorageEvent
      4 log: initMouseEvent
      4 log: initMessageEvent
      4 log: initEvent
      4 log: initCustomEvent
      4 log: initCompositionEvent
      3 log: initTextEvent
      3 log: initKeyboardEvent
      3 log: initDeviceOrientationEvent
      3 log: initDeviceMotionEvent
      2 log: initHashChangeEvent
      2 log: initDragEvent
      1 log: initWheelEvent
      1 log: initTransitionEvent
      1 log: initProgressEvent
      1 log: initPopStateEvent
      1 log: initFocusEvent
      1 log: initErrorEvent
      1 log: initCloseEvent
      1 log: initAnimationEvent

[ArkadiuszMichalski]

In the simplest case all of them can be initial via initEvent() so in some sense they can always be send by dispatchEvent(). Also worth carefully check accepted the arguments in each of these methods because I remember that in some cases browsers works differently (when reading and testing some from UI Event).

[foolip]

Should we close this now, or are there more we know are hard to remove and should be added? @inexorabletash? (via https://bugs.chromium.org/p/chromium/issues/detail?id=697170#c4)

[inexorabletash]

Sorry, missed the ping, and I'm unsure of the goal here. There are a set of init*Event() methods that are implemented in browsers, but not standardized. Are we hoping to remove those from browsers rather than documenting?

[foolip]

I think the only remaining non-standard one that would end up HTML is initStorageEvent (https://bugs.chromium.org/p/chromium/issues/detail?id=697170#c4) and from web-confluence.appspot.com I can see that it's all browsers. So we should probably just add that one?

[foolip]

Here it is in Blink, Gecko and WebKit:

• https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/storage/storage_event.idl?l=38&rcl=59048c8cc3894851410543095756e0e74ffe1cc5
• https://github.com/mozilla/gecko-dev/blob/679b5e2db1bc607cff5ad8640eb9a4b3626e4cf9/dom/webidl/StorageEvent.webidl#L23
• https://github.com/WebKit/webkit/blob/8da57840865d2f45ef5e27c8db2ee7d6b8f5e3ce/Source/WebCore/storage/StorageEvent.idl#L36

I'd suggest this definition:

void initStorageEvent(DOMString type,
  optional boolean bubbles = false,
  optional boolean cancelable = false,
  optional DOMString? key = null,
  optional DOMString? oldValue = null,
  optional DOMString? newValue = null,
  optional USVString url = "",
  optional Storage? storageArea = null);

[inexorabletash]

Ah! SGTM. That looks fine. Looks like there might be variation in how null/undefined for key is handled across browsers, but we can test.

[foolip]

Yes, there will be some differences in number of required arguments, maybe default values, and probably in how undefined is interpreted. Will require some tests indeed. Probably doesn't matter much though :)