Intent to Deprecate and Remove: “which” field from KeyboardEvent.idl and MouseEvent.idl

62 views
Skip to first unread message

Mustaq Ahmed

unread,
Apr 28, 2017, 6:21:33 PM4/28/17
to blink-dev

Primary eng email

mus...@chromium.org


Summary

Remove the “which” field from KeyboardEvent.idl and MouseEvent.idl. Currently the field is already defined in UIEvent.idl. After the proposed removal, KeyboardEvent and MouseEvent instances will simply inherit the field from UIEvent, and the actual field value will remain unchanged for them.


Motivation

Until very recently, only the KeyboardEvent spec had defined the “which” field, and none of the KeyboardEvent & MouseEvent spec did. However, MouseEvent.which was available in both Chrome and Edge. The spec discussion to resolve this discrepancy (https://github.com/w3c/uievents/issues/35) concluded last year with the decision to move the “which” field from KeyboardEvent to UIEvent.


The spec has been fixed this week (https://github.com/w3c/uievents/commit/cfe977225970f4ae2cd2e6430977001b40e9382e). It’s time to align Chrome with the spec.


Interoperability and Compatibility Risk

There is very little compatibility risk because instances of both KeyboardEvent and MouseEvent will have unchanged values for “which”. The only visible change will be the field being inherited from the UIEvent instead, which will change the values of the expressions

 KeyboardEvent.prototype.hasOwnProperty(“which”)

and

 MouseEvent.prototype.hasOwnProperty(“which”)

from “true” to “false”. Only a handful of websites (if any) should be affected by this because of differences in current implementations, see below.


Interop risk is nearly zero because no two browsers are currently consistent about where they define the “which” field:

https://github.com/w3c/uievents/issues/35#issuecomment-297822323


Edge: Supported, already committed to the change (https://github.com/w3c/uievents/issues/35#issuecomment-148487639).

Firefox: Current implementation already follows the new spec.

Safari: No signal. Currently doesn’t have “which” in MouseEvent.idl.


Alternative implementation suggestion for web developers

The “which” field will still be available in KeyboardEvent and MouseEvent instances through inheritance.


Usage information from UseCounter

KeyboardEvent.which: no data

MouseEvent.which: https://www.chromestatus.com/metrics/feature/timeline/popularity/595

UIEvent.which: https://www.chromestatus.com/metrics/feature/timeline/popularity/598


OWP launch tracking bug

crbug.com/692717


Entry on the feature dashboard

None. This change doesn’t need outreach to developers because the visible change is very small.


Requesting approval to remove too?

Yes


Rick Byers

unread,
Apr 28, 2017, 10:59:03 PM4/28/17
to Mustaq Ahmed, blink-dev
LGTM1 without a deprecation period.  This is one of those cases where the UseCounter/deprecation warning is worse than useless :-(.  I agree the compat risk should be very low.

Chris Harrelson

unread,
May 3, 2017, 8:34:58 PM5/3/17
to Rick Byers, Mustaq Ahmed, blink-dev
LGTM2

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

Mustaq Ahmed

unread,
May 9, 2017, 10:09:04 AM5/9/17
to blink-dev, Rick Byers, Chris Harrelson
I need one more LGTM to go ahead (unless there are questions/concerns).

nurul...@gmail.com

unread,
May 9, 2017, 11:15:49 AM5/9/17
to blink-dev
Yes

Jochen Eisinger

unread,
May 9, 2017, 12:31:55 PM5/9/17
to nurul...@gmail.com, blink-dev
lgtm3

On Tue, May 9, 2017 at 5:15 PM <nurul...@gmail.com> wrote:
Yes

Reply all
Reply to author
Forward
0 new messages