New issue
Advanced search Search tips

Issue 701480 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Task

Blocking:
issue 674593


Show other hotlists

Hotlists containing this issue:
Non-Standard-IDL


Sign in to add a comment

Remove the textinput event and the TextEvent interface

Project Member Reported by lunalu@chromium.org, Mar 14 2017

Issue description

Comment 1 by tkent@chromium.org, Mar 15 2017

Components: -Blink>DOM>Events Blink>DOM
Remove Blink>DOM>Events

Comment 2 by tkent@chromium.org, Mar 17 2017

Components: -Blink>DOM Blink>Editing
Labels: Hotlist-Interop
Status: Available (was: Untriaged)

Comment 3 by foolip@chromium.org, Apr 14 2017

Cc: dtapu...@chromium.org
Summary: Remove the textinput event and the TextEvent interface (was: Remove TextEvent)
dtapuska@, do you know anything about this event?

Comment 4 by yosin@chromium.org, Apr 14 2017

We have UMA for textinput event:

https://www.chromestatus.com/metrics/feature/popularity#TextInputFired
0.0872%

And more:
- TextInputEventOnInputObsolete  0.1844%
- TextInputEventOnInput 0.0245%
- TextInputEventOnTextAreaObsolete 0.0213%
- TextInputEventOnTextArea 0.0065%
- TextInputEventOnContentEditableObsolete 0.0095%
- TextInputEventOnContentEditable 0.0697%
- TextInputEventOnNotNode <=0.0001%

It seems >= 0.003% :-<



Comment 5 by foolip@chromium.org, Apr 14 2017

There's also https://www.chromestatus.com/metrics/feature/timeline/popularity/831 which is how often the data attribute is accessed, which means that the event listener is actually doing something. That's at ~0.08%.

We don't have a fixed threshold for removal, but usage is certainly high enough that we would want to understand why, and what the breakage would be.

It looks like WebKit and EdgeHTML also have a TextEvent interface, although I haven't checked when events are fired. A good next step here would be to write some basic tests for when these events are fired, and see how interoperable it already is between the 3 engines that do support it.

Is this event supposed to be made obsolete by the new beforeinput and input events?
Labels: -Type-Bug Type-Task

Comment 7 by flackr@chromium.org, May 16 2018

FYI, removing textinput is already mentioned in issue 382814.

The textinput event is used in react:
https://github.com/facebook/react/blob/e96dc140599363029bd05565d58bcd4a432db370/packages/react-dom/src/events/BeforeInputEventPlugin.js#L43

Note that they have a fallback in the event that textinput is not available:
https://github.com/facebook/react/blob/e96dc140599363029bd05565d58bcd4a432db370/packages/react-dom/src/events/BeforeInputEventPlugin.js#L404

It's possible that react is the reason for these high usage numbers, access of the data attribute (when textinput is detected as available) is here:
https://github.com/facebook/react/blob/e96dc140599363029bd05565d58bcd4a432db370/packages/react-dom/src/events/BeforeInputEventPlugin.js#L300

So, we could test if there would be any breakage for react if we were to remove textinput. Would it make sense to create a use counter which measures non-react usage (caveat: I don't know how we would do this - maybe the script name)?

Also, we could modify react to prefer using the beforeinput event which has been implemented ( issue 585875 ).

Sign in to add a comment