Confirming this occurs for me too:

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3365.0 Safari/537.36

Version 67.0.3365.0 (Official Build) canary (64-bit)
OS Version: 10.13.1 (17B1003)

Deleted: chrome-repeat.gif 117 KB

	chrome-repeat.gif 117 KB View Download

Able to reproduce the issue on reported chrome version 67.0.3365.0 using Mac 10.12.6 hence providing Bisect Info
Note: Issue is not seen in Ubuntu 14.04 and Windows-10

Bisect Info:
================
Good build: 67.0.3362.0
Bad build: 67.0.3364.0

You are probably looking for a change made after 540879 (known good), but no later than 540880 (first known bad).

https://chromium.googlesource.com/chromium/src/+log/7bea94e12121bc43c45d68779803b5628f7ebbf1..a0259b3ae165b0673416f02848bed75082d639f4

Reviewed-on:https://chromium-review.googlesource.com/941883

@Robert Liao: Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable as it is seems a receent break, feel free to remove it if not applicable.

Thanks!

I'm able to repro. Investigating.

And verified this is mac only.

The bug here is that in handling a Keyboard ACK, Cocoa goes ahead and redispatches the event. Views browser treats this as an unhandled event and sends it to the system without further handling.

* thread #1, name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x00000001224dc98a libcontent.dylib`content::InputRouterImpl::SendKeyboardEvent(this=0x000000015d0c2600, key_event=0x00007ffeefbf5d60) at input_router_impl.cc:120
    frame #1: 0x00000001227792f5 libcontent.dylib`content::RenderWidgetHostImpl::ForwardKeyboardEventWithCommands(this=0x000000015d049a00, key_event=0x00007ffeefbf6df0, latency=0x00007ffeefbf68e0, commands=0x000000015c51e128 size=1, update_event=0x0000000000000000) at render_widget_host_impl.cc:1422
    frame #2: 0x00000001227da245 libcontent.dylib`::-[RenderWidgetHostViewCocoa keyEvent:wasKeyEquivalent:](self=0x000000015c51df80, _cmd="keyEvent:wasKeyEquivalent:", theEvent=0x000062c000123520, equiv=NO) at render_widget_host_view_mac.mm:2224
    frame #3: 0x00000001227d88cb libcontent.dylib`::-[RenderWidgetHostViewCocoa keyEvent:](self=0x000000015c51df80, _cmd="keyEvent:", theEvent=0x000062c000123520) at render_widget_host_view_mac.mm:2071
    frame #4: 0x00000001016169da libui_base.dylib`::-[BaseView keyDown:](self=0x000000015c51df80, _cmd="keyDown:", theEvent=0x000062c000123520) at base_view.mm:172
    frame #5: 0x00007fff31da9029 AppKit`-[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 5040
    frame #6: 0x00007fff31da785c AppKit`-[NSWindow(NSEventRouting) sendEvent:] + 497
    frame #7: 0x000000013648dcd3 libviews.dylib`::-[NativeWidgetMacNSWindow sendEvent:](self=0x0000000155a04c10, _cmd="sendEvent:", event=0x000062c000123520) at native_widget_mac_nswindow.mm:148
    frame #8: 0x00007fff31c08fa3 AppKit`-[NSApplication(NSEvent) sendEvent:] + 2751
    frame #9: 0x0000000105da15f5 libchrome_dll.dylib`::__34-[BrowserCrApplication sendEvent:]_block_invoke(.block_descriptor=0x00007ffeefbf7618) at chrome_browser_application_mac.mm:268
    frame #10: 0x000000011ab3be4a libbase.dylib`base::mac::CallWithEHFrame(void () block_pointer) at call_with_eh_frame_asm.S:36
    frame #11: 0x0000000105da137f libchrome_dll.dylib`::-[BrowserCrApplication sendEvent:](self=0x0000618000120140, _cmd="sendEvent:", event=0x000062c000123520) at chrome_browser_application_mac.mm:251
    frame #12: 0x00000001016180bc libui_base.dylib`::-[CommandDispatcher redispatchKeyEvent:](self=0x0000618000025cc0, _cmd="redispatchKeyEvent:", event=0x000062c000123520) at command_dispatcher.mm:165
    frame #13: 0x000000010b8eab2e libchrome_dll.dylib`::-[ChromeEventProcessingWindow redispatchKeyEvent:](self=0x0000000101404d00, _cmd="redispatchKeyEvent:", event=0x000060000012b7c0) at chrome_event_processing_window.mm:49
    frame #14: 0x000000010b8e4bb3 libchrome_dll.dylib`::+[BrowserWindowUtils handleKeyboardEvent:inWindow:](self=BrowserWindowUtils, _cmd="handleKeyboardEvent:inWindow:", event=0x000060000012b7c0, window=0x0000000101404d00) at browser_window_utils.mm:71
    frame #15: 0x000000010b8b7f46 libchrome_dll.dylib`BrowserWindowCocoa::HandleKeyboardEvent(this=0x000061c00006e800, event=0x00006040001c15d0) at browser_window_cocoa.mm:599
    frame #16: 0x000000010b3b6c58 libchrome_dll.dylib`Browser::HandleKeyboardEvent(this=0x00000001014041e0, source=0x000000015d03b800, event=0x00006040001c15d0) at browser.cc:1261
    frame #17: 0x000000010bcad441 libchrome_dll.dylib`ExtensionViewViews::HandleKeyboardEvent(this=0x0000000155a12c70, source=0x000000015d03b800, event=0x00006040001c15d0) at extension_view_views.cc:102
    frame #18: 0x0000000109d58c13 libchrome_dll.dylib`extensions::ExtensionViewHost::UnhandledKeyboardEvent(this=0x000000015c500210, source=0x000000015d03b800, event=0x00006040001c15d0) at extension_view_host.cc:111
    frame #19: 0x0000000109d591f1 libchrome_dll.dylib`extensions::ExtensionViewHost::HandleKeyboardEvent(this=0x000000015c500210, source=0x000000015d03b800, event=0x00006040001c15d0) at extension_view_host.cc:204
    frame #20: 0x0000000122c4af5c libcontent.dylib`content::WebContentsImpl::HandleKeyboardEvent(this=0x000000015d03b800, event=0x00006040001c15d0) at web_contents_impl.cc:1978
    frame #21: 0x0000000122782635 libcontent.dylib`content::RenderWidgetHostImpl::OnKeyboardEventAck(this=0x000000015d049a00, event=0x00006040001c15d0, ack_source=MAIN_THREAD, ack_result=INPUT_EVENT_ACK_STATE_NOT_CONSUMED) at render_widget_host_impl.cc:2387

To add some more color to this, when ExtensionViewViews gives the browser a shot at handling the event, the Browser window says cool, I'll go ahead and redispatch it a la [NSApp sendEvent:keyEvent].

However, [NSApp sendEvent:] sends key events to the key (currently focused) window, which is the Extension Popup Widget Window. It receives the NSEvent and says, hey, I'll go ahead and send this on but it doesn't know it already received the event before.

Unmarking ReleaseBlock-Dev. The main workaround here is to temporarily disable secondary UI while I fix the issue.

chrome://flags/#secondary-ui-md -> disabled

 Issue 820406  has been merged into this issue.

 Issue 820928  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d113e604046fadcb119a541537ae21783812cdc3

commit d113e604046fadcb119a541537ae21783812cdc3
Author: Robert Liao <robliao@chromium.org>
Date: Mon Mar 12 19:59:14 2018

Remove Unhandled Key Forwarding to the Browser

Browser unhandled keyboard event forwarding was added for 130131, but
is incompatible with the way Mac dispatches events. Views unhandled
keyboard event forwarding was added for 145184 and should be the main
way to cover this scenario for all platforms.

BUG= 130131 , 145184 , 820208 

Change-Id: Ia6fd96b6059a5b5932e186299a0769b6a931c356
Reviewed-on: https://chromium-review.googlesource.com/957975
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: Robert Liao <robliao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542574}
[modify] https://crrev.com/d113e604046fadcb119a541537ae21783812cdc3/chrome/browser/ui/views/extensions/extension_view_views.cc

Able to reproduce the issue on chrome reported version 67.0.3365.0
Verified the fix on Mac 10.12.6 on Chrome version #67.0.3370.0 as per the comment#0
Attaching screen cast for reference.
Observed "A single character per key press appears"
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 820208.mp4 1.0 MB

	820208.mp4 1.0 MB View Download