Intent to Remove: legacy constants on Event

[Philip Jägenstedt]

Summary

The Event interface has 16 constants corresponding to event types from a distant past. The values aren't used anywhere, they merely exist.

Remove the constants with no deprecation period (They aren't deprecated and there as been no Intent to Deprecate, see UseCounter section for why).

Motivation

The other option is to standardize them:

https://github.com/whatwg/dom/issues/334

Tests for the non-support were added in https://github.com/w3c/web-platform-tests/pull/4355 and running the test shows that only Blink and WebKit have these constants, Edge and Gecko do not. (These constants appears to be a Netscape-era thing, but as fascinating as it would be I haven't dug into when support was added and removed.)

Compatibility Risk

Quoting a comment from https://crbug.com/674944:

I've taken a look at '.MOUSEDOWN' matches in httparchive:har.2016_11_15_chrome_requests_bodies There are 7006 matches (from ~500k pages crawled) and after checking a random subset of about 20 all of the non-bogus matches were this pattern: if (document.layers) { document.captureEvents(Event.MOUSEDOWN); document.onmousedown = clickNS4; }

captureEvents() has long ago been neutered to do nothing, so this would not break. An exhaustive analysis of all the constants doesn't seem warranted.

For WebKit-only things one should normally worry that its were existence is used by some script to detect WebKit without UA sniffing, but that this was once in Netscape and wasn't added to Edge suggests that this isn't widespread if it happens at all.

Alternative implementation suggestion for web developers

These constants do nothing, but if they are used in some mysterious way, just use these numbers instead:

MOUSEDOWN = 1 MOUSEUP = 2 MOUSEOVER = 4 MOUSEOUT = 8 MOUSEMOVE = 16 MOUSEDRAG = 32 CLICK = 64 DBLCLICK = 128 KEYDOWN = 256 KEYUP = 512 KEYPRESS = 1024 DRAGDROP = 2048 FOCUS = 4096 BLUR = 8192 SELECT = 16384 CHANGE = 32768

Usage information from UseCounter

None. Attributes on event cannot be usefully measured due to event copying patterns that greatly inflate the usage. This is also why deprecation is not a good idea. The message would overwhelmingly be noise, and we have found code in the wild to explicitly avoid hitting bogus deprecation messages, which wouldn't be a good use of developer's time.

OWP launch tracking bug

https://crbug.com/674944

Entry on the feature dashboard

https://www.chromestatus.com/feature/5723085873348608

(Status will be updated when it's clear which milestone the removal will be in.)

[PhistucK]

Did you try to dig out the reason for their addition to WebKit (though I imagine it would be a KHTML addition)?

☆PhistucK

--
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.

[Philip Jägenstedt]

They were merged from KHTML in 2002, not long after the fork. The kdelibs change was motivated by site compat, referencing www.maschbau-ac.de. That's gone, but the Internet Archive has copies, although I can't find a place where the sites looks functional. That was all 15 years ago :)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Harrelson]

Hi,

Could you do some more research for the other values equivalent to what you did for MOUSEDOWN for the others and verify those?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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.

[Rick Byers]

Using HTTPArchive to dig into a random sampling of matches like that can be pretty tedious and time consuming.  I did some simple regex searching on nerdydata.com for each of these strings (had problems using a RegEx with sub-expressions) and scanned over the first page (50 results) for each:

• Most results were captureEvents/releaseEvents.
• A few were obviously bogus (passing the value to addEventListener in place of an event name).
• The CLICK case was probably most interesting. 
• I found one case that appeared to be using the values legitimate as bitmasks but it was behind an "if(ns4)" guard which is true only when !document.getElementById.
  
• A few were defining such values themselves (eg. Event.MOUSEDOWN="mousedown", H.Event.MOUSEDOWN=1)

But from that I didn't find any that looked like they could be breaking.  This is far from an exhaustive search though.

Given:

• There's no useful way to use these (so "undefined" is likely just as good as getting one of these numbers)
• Edge and Firefox have apparently never run into a site compat issues due to not having these (I did some searching at bugzilla.mozilla.org)
  
• HTTPArchive searches return a lot of noise making it impossible (or at least very time consuming) to statically find evidence of a low rate of breakage 
• UMA can't be used to measure usage for the reason Philip mentions

I support Philip's suggestion of just removing them and keeping an eye out for reports of breakage.  LGTM1

[Chris Harrelson]

Thanks for the additional data.

LGTM2

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[Philip Jägenstedt]

Thank you all!

LGTM3.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.