Intent to Deprecate and Remove: Blink-WebKit-only document.createEvent strings

[Philip Jägenstedt]

Primary eng (and PM) emails

foo...@chromium.org

Summary

Now that document.createEvent will no longer automatically support new event interfaces, I'll also try to remove some things that have been added automatically that don't make sense and (probably) aren't needed for compat.

In this batch, drop 29 strings that are supported only in Blink, and 5 that are only in WebKit+Blink. See use counters below for a complete list. 

Motivation

The way that scrips create events on the web platform has from

var event = document.createEvent('MouseEvent');

event.initMouseEvent(/* very long argument list */);

to

var event = new MouseEvent('mousemove', /* dictionary */);

Without the init*Event() method, support in createEvent doesn't really make sense.

Compatibility Risk

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4355 was used to test recent versions of Chrome, Firefox and Edge on Windows, and Safari on Mac. The interfaces that were supported only in Chrome or in Chrome+Safari were identified.

Even without init*Event() methods, document.createEvent is probably used for feature detection sometimes. This would be a concern if usage were high, like in the case of WebKitTransitionEvent, but not here.

Alternative implementation suggestion for web developers

Use e.g. new BlobEvent('foo' { data: blob }) to create a BlobEvent, or 'BlobEvent' in window for feature testing.

Usage information from UseCounter

The 29 Blink-only strings:

• ApplicationCacheErrorEvent
  
• BeforeInstallPromptEvent
  
• BlobEvent
  
• ClipboardEvent
  
• ExtendableEvent
  
• ExtendableMessageEvent
  
• FetchEvent
  
• FontFaceSetLoadEvent
  
• GamepadEvent
  
• MediaEncryptedEvent
  
• MediaQueryListEvent
  
• MediaStreamEvent
  
• MediaStreamTrackEvent
  
• MIDIConnectionEvent
  
• MIDIMessageEvent
  
• NotificationEvent
  
• PresentationConnectionAvailableEvent
  
• PresentationConnectionCloseEvent
  
• PromiseRejectionEvent
  
• PushEvent
  
• ResourceProgressEvent
  
• RTCDataChannelEvent
  
• RTCDTMFToneChangeEvent
  
• RTCIceCandidateEvent
  
• SecurityPolicyViolationEvent
  
• ServiceWorkerMessageEvent
  
• SpeechRecognitionError (weird name!)
  
• SpeechRecognitionEvent
  
• SyncEvent

The 5 WebKit-Blink-only strings:

• AudioProcessingEvent
  
• MediaKeyMessageEvent
  
• OfflineAudioCompletionEvent
  
• OrientationEvent (alias for Event)
  
• SpeechSynthesisEvent
  

All of these have usage that rounds to 0%. From internal data, the 28 day aggregates are all in the range 0-9, i.e. they're all hit only once every few days on average.

Note that these WebKit-Blink-only strings are left alone:

• KeyboardEvents, which is now in the DOM spec
  
• WebKitAnimationEvent and WebKitTransitionEvent, which are aliases of AnimationEvent and TransitionEvent, and it's probably best to consider their fate separately.

OWP launch tracking bug

I will use crbug.com/569690 which is not an OWP launch tracking bug.

Entry on the feature dashboard

None. Given the usage I don't think it's worth trying to summarize this change as a single thing, and one entry per string would be way overkill.

Requesting approval to remove too?

Yes. A deprecation message would likely reach zero people given the usage.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

See my comment inline (select and reply workflow in GMail stopped working? Weird :().

☆PhistucK

Entry on the feature dashboard

None. Given the usage I don't think it's worth trying to summarize this change as a single thing, and one entry per string would be way overkill.

​I am not sure I agree regarding a single entry. Think about enterprise environments where usage might be non-zero and not reported.​

[Philip Jägenstedt]

I'll defer to Joe about whether a feature dashboard entry would be useful. I do plan to deprecate and then remove a few of the things that remain, and for that an entry will be needed. If it were possible to just write a single page explaining the situation (in all engines) I think that would be more useful, but where?

[Philip Jägenstedt]

Correction: I wrote "KeyboardEvents, which is now in the DOM spec" but that alias for KeyboardEvent is actually not in the spec. Still, I'm leaving it out of this intent because its usage is significantly higher than the others included, although still very low.

[dk...@google.com]

Is this intent blocked on API owner feedback?

[Philip Jägenstedt]

Ping!

[Rick Byers]

LGTM2

The usage is so low that this is arguably just a bug-fix (we were incorrectly supporting non-standard behavior that nobody appears to be relying on).  I personally think a chromestatus entry is overkill, although perhaps a link could be added to some more generic entry about deprecating old-style event construction patterns?

Rick

[Dave Tapuska]

What is our take on the case insensitivity? The spec (more recently) got updated so it dealt with case insensitivity. (And subsequently someone opened issue 603614)

dave.

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

Thanks all.

Rick, I'll just not create a chromestatus entry for this, given the fantastically low usage.

Dave, on case insensitivity, I'll comment on issue 603614.