DevTools: pressing enter in bound input fields should not fire change handler

third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js

Index: third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js
diff --git a/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js b/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js
index d2d831687423820b9c2657c6cf241453dc47f02f..ad40bfbcbc207df3a071c0965e5a3aeacaa6b9b5 100644
--- a/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js
+++ b/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js
@@ -1558,12 +1558,6 @@ UI.bindInput = function(input, apply, validate, numeric) {
    * @param {!Event} event
    */
   function onKeyDown(event) {
-    if (isEnterKey(event)) {

[dgozman, 2017/04/27 22:58:55]

Why was this introduced in first place? Was it there for old non-instant mode?
Could you find a patch which did it?

Let's double check all the clients to see whether they continue to work with
enter key.

[luoe, 2017/04/29 03:29:59]

As far as I can tell, the history looks like this:

https://codereview.chromium.org/45363004
The first instance of listening for Enter on keydown is introduced in
OverridesView.js for 'createInput()'.  No 'change' listeners or validators, here
we only applied the value on Enter and blur.

https://codereview.chromium.org/304693002
Instant flag introduced on createSettingInputField, we only apply values if the
input is 'instant' or we 'blur'.  We start listening for 'change' events, but
only do validation and not apply on changes.

https://codereview.chromium.org/315003008
createSettingInputField now gets 'keydown' for applying on Enter.  All clients
of createSettingInputField provided either a validator or instant == true, so
they all should have listened to 'change' events.

https://codereview.chromium.org/1642233002
Finally, createSettingInputField was removed during a large cleanup, and we
ended up with today's bindInput as its replacement.

Commentary:
Today, both 'change' events and pressing Enter can apply the new value.  For
DeviceModeToolbar's width/height input and Workspace's exclude file pattern, it
doesn't really make sense to apply on Enter if the 'change' listener is already
at work.  After playing around with the geolocation/orientation inputs, I
realize why this doesn't always apply.  If we're doing
geolocation.watchPosition(), I can imagine a workflow where pressing Enter is
useful to forcefully trigger your callback to run.

As such, I've instead kept the enter logic and just added a preventDefault so
that the change handler doesn't fire after it.

-      if (validate(input.value))
-        apply(input.value);
-      return;
-    }
-
     if (!numeric)
       return;