GitLab

Mac key event handling works by first sending a key to the renderer.
When the renderer ACKs the event as unconsumed, the browser re-injects
the NSEvent back into the app. This is done so that the browser can
perform commands if the renderer didn't consume them (e.g. Command-T).

The Event.Latency.OS_NO_VALIDATION metric was temporarily added to
investigate the cause of long instances in the InputDelay metric. It
measures the delta between the event's OS-provided timestamp and the
current time when a WebKeyboardEvent is built from an NSEvent. This
metric is meant to narrow down where these long InputDelay values are
coming from.

OS_NO_VALIDATION assumes that the call to it happens close to where the
OS event is received by Chrome.  However, the reinjection mechanism
mentioned at the top breaks this assumption. When the event is
reinjected, there are cases where it must be passed to the content/
layer (e.g. when being passed to the Views FocusManager[1]) and a
WebKeyboardEvent is reconstructed.  Hence we record this metric multiple
times for such events, the second time causing the metric to depend on
delays in the jank.

This can reproduced by visiting a page with a very busy main thread
(e.g.  https://rbyers.github.io/scroll-latency.html and set a high
periodic jank) and performing "key equivalents" (i.e. browser commands
like Command-C) while the main thread is blocked. You'll notice very
high values reported in [2].

This CL adds a temporary constructor to NativeWebKeyboardEvent on Mac
that causes us to record this metric only on the code path that will
eventually send the event to the renderer (i.e.  avoid reinjected
events). This is temporary to prove this hypothesis and determine how
much of the problematic reports are due to other causes. It will be
reverted after a few days of data is collected.

Note: In https://crrev.com/4a7404eceeb I added a DumpWithoutCrash in
cases where we saw a big discrepancy in the Now() and event timestamp.
The issue addressed in this CL shows up in these stacks but there are
other cases that have a big discrepancy and are captured from
RenderWidgetHostViewCocoa::keyEvent. This CL will help cut down on the
noise so we can keep diagnosing the root cause.

[1] https://cs.chromium.org/chromium/src/chrome/browser/ui/cocoa/chrome_command_dispatcher_delegate.mm?l=44&rcl=fb1021a791d9141b4df6d639f0d50bfe0c0ce944
[2] chrome://histograms/Event.Latency.OS_NO_VALIDATION.POSITIVE.KEY_PRESSED


Bug: 1039833
Change-Id: I17af7f76db0f69024ec75b45822d69178a4cd565
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2129238
Commit-Queue: David Bokan <bokan@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#755118}