Intent to Deprecate and Remove: UIEvent.charCode/keyCode

[Paritosh Kumar Monu]

Contact emails

parit...@samsung.com

Summary

Deprecate and Remove charCode and keyCode attributes from UIEvent, as these should be on KeyBoardEvent only.

Spec: https://w3c.github.io/uievents/#interface-UIEvent

Motivation

In both Firefox and IE, the charCode and keyCode attributes are on the KeyboardEvent interface, not UIEvent.

https://code.google.com/p/chromium/issues/detail?id=508316

Compatibility Risk

Usage for these attributes are high

UIEventCharCode: 4.32 %

UIEventKeyCode: 6.17 %

But both Firefox and IE, exposes this on KeyBoardEvent interface only.

Alternative implementation suggestion for web developers

In Blink, these attribute always return 0 except for keyboard events. After removal they would instead return undefined.

Usage information from UseCounter

UIEventCharCode: https://www.chromestatus.com/metrics/feature/timeline/popularity/596

UIEventKeyCode: https://www.chromestatus.com/metrics/feature/timeline/popularity/597

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=508316

Requesting approval to remove too?

As usage are high, we should first deprecate it and probably we can remove it after 2 or 3 release cycles.

Paritosh

[Philip Jägenstedt]

LGTM to remove without deprecation.

The use counter data looks scary, but given the other facts it doesn't
seem plausible that this is an actual interop problem. Of course, if
we see any breakage at all, we should revert immediately to see what's
going on.

The reason I don't think we should deprecate is also the high usage,
that would be very spammy, and at most a minuscule fraction of that
usage could be code that's going to break from the change.

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

[Rick Byers]

I agree with the plan to do immediate removal without deprecation but watch closely for issues.

We've seen a number of these 'on the wrong interface, use counter data seems useless' situations now.  I was having some trouble imagining why it was THIS common so I did a little experiment where I break on access to UIEvent.keyCode.  It turns out the first site I tried (GMail) does this ALL the time - for every single mouse event, looks like it's making a copy of the UIEvent:

    kd.prototype.init = function(a, b) {

        var c = this.type = a.type;

        this.target = a.target || a.srcElement;

        this.currentTarget = b;

        var d = a.relatedTarget;

        d ? Vc && (Tca(d, "nodeName") || (d = null )) : "mouseover" == c ? d = a.fromElement : "mouseout" == c && (d = a.toElement);

        this.relatedTarget = d;

        this.offsetX = Xc || void 0 !== a.offsetX ? a.offsetX : a.layerX;

        this.offsetY = Xc || void 0 !== a.offsetY ? a.offsetY : a.layerY;

        this.clientX = void 0 !== a.clientX ? a.clientX : a.pageX;

        this.clientY = void 0 !== a.clientY ? a.clientY : a.pageY;

        this.screenX = a.screenX || 0;

        this.screenY = 

        a.screenY || 0;

        this.button = a.button;

        this.keyCode = a.keyCode || 0;

        this.charCode = a.charCode || ("keypress" == c ? a.keyCode : 0);

        this.ctrlKey = a.ctrlKey;

        this.altKey = a.altKey;

        this.shiftKey = a.shiftKey;

        this.metaKey = a.metaKey;

        this.xr = Zc ? a.metaKey : a.ctrlKey;

        this.state = a.state;

        this.We = a;

        a.defaultPrevented && this.preventDefault()

    }.  I 

If this sort of copying pattern is really common in event libraries, then I guess we're not going to learn much from the use counters.  In general for event properties I'm fine disregarding the user counter data and relying on whether the API has any value (i.e. scenarios that return only constants are pretty useless) and what other major browsers do.  There's some risk for Chromium-specific code (eg. Android WebView and Chrome apps), but I think it's manageable.

Rick

[Philip Jägenstedt]

That's very interesting, Rick! In the face of that kind of code on popular sites, the use counter data really is useless.

[Rick Byers]

On Fri, Jul 10, 2015 at 9:59 AM, Philip Jägenstedt <phi...@opera.com> wrote:

That's very interesting, Rick! In the face of that kind of code on popular sites, the use counter data really is useless.

This GMail event-cloning code is even more interesting (from our other discussion of UIEvent.which):

        for (c in a)
            b[c] = a[c];

I doubt it's only Gmail doing this sort of thing (lots of people like event-wrapping/delegation libraries).  

[TAMURA, Kent]

LGTM2.

it's ok to skip deprecation according to Rick's analysis.

--

TAMURA Kent
Software Engineer, Google

[Chris Harrelson]

LGTM3. Please watch carefully for regressions.