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

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

 /*
  * Copyright (C) 2011 Google Inc.  All rights reserved.
  * Copyright (C) 2006, 2007, 2008 Apple Inc.  All rights reserved.
  * Copyright (C) 2007 Matt Lilek (pewtermoose@gmail.com).
  * Copyright (C) 2009 Joseph Pecoraro
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  *
@@ skipping 1540 matching lines @@
     var valid = validate(input.value);
     input.classList.toggle('error-input', !valid);
     if (valid)
       apply(input.value);
   }
 
   /**
    * @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;
 
     var increment = event.key === 'ArrowUp' ? 1 : event.key === 'ArrowDown' ? -1 : 0;
     if (!increment)
       return;
     if (event.shiftKey)
       increment *= 10;
 
     var value = input.value;
@@ skipping 494 matching lines @@
    */
   constructor(message, okCallback, cancelCallback) {
     super(true);
     this.registerRequiredCSS('ui/confirmDialog.css');
     this.contentElement.createChild('div', 'message').createChild('span').textContent = message;
     var buttonsBar = this.contentElement.createChild('div', 'button');
     buttonsBar.appendChild(UI.createTextButton(Common.UIString('Ok'), okCallback));
     buttonsBar.appendChild(UI.createTextButton(Common.UIString('Cancel'), cancelCallback));
   }
 };