Can you provide a reproduction app that we can try?

https://chrome.google.com/webstore/detail/testnav/mdmkkicfmmkgmpkmkdikhlbggogpicma?hl=en. After you launch the app, press the "<-" key. This key was blocked on prior versions of cros

+dtapuska to see the example in #2

Any updates on this yet?

any updates on this?

I tried this on a Chrome Pixelbook 61.0.3163.110 and I don't see the issue.

I loaded the app in comment #1 which opened a new window. And then I task switched to chrome://inspect, chose the App opened the console for it

with monitorEvents(window, "keydown"); then task switched back to the app and it records all the keys that I press in the console.

This does not dispatch events for back, refresh, fullscreen or minimize screen brightness but does for every key on my chromebook.

What keys are you indicating it isn't being reported for?

For us the key handler function wasn't being called at all on any keypress.  It seems like this behavior may have been very specific to certain versions of Chrome (61.0.3163.123) so I will have our internal testers try this again and see if they can narrow it down.  If it all seems to be working on the latest stable versions then we may not have an issue.

I've tried on Chrome 62.0.3202.82 as well. Do you have any other extensions installed?

The NextAction date has arrived: 2017-11-14

Our testers tried this again in61.0.3163.123 and 62.0.3202.82 along with the 63 beta channel version, and are now reporting the key handlers are working fine.  We had multiple people recreate this internally, so maybe there was something with a very particular Chrome version that we ran into.  Since it appears to be working now, this can be closed.  Thanks for your help!

I had this same issue today, and here are the specs for my Chromebook:

UserAgent: Mozilla/5.0 (X11; CrOS armv7l 10032.59.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.70 Safari/537.36
Platform: 10032.59.0 (Official Build) beta-channel veyron_minnie
Chrome version: 63.0.3239.70  Channel: beta
OS Version: 10032.59.0

yup, this issue is still happening. Can we guys try it again and get it fixed?

dtapuska@ can you take another look at this given that we've gotten some reports this is now recurring on M63?  There is also info on  crbug.com/799471 , which I will dupe into this one.

 Issue 799471  has been merged into this issue.

I still can't make this happen. Is it possible to provide a screen recording of the problem.

And if so can you open devtools (via going to chrome://inspect/#apps and click the associated tab) and then in the console monitorEvents(window, "keydown");

I see this still today.  My Chromebook is on Chrome 64.0.3282.87.

We have the keydown listener on the window, and a webview loaded inside.  The keydown event handler on the window is not triggered by a keydown in the webview.  

I took a screen recording of the app and a secondary window with the console.  I added a keydown listener to the window and to the webview just to log keydown events, and you can see that the key is only logged in the webview, not the window.  First I pressed TAB for a test, then the Chromebook back button.

Deleted: chromeapp-keydown.mp4 732 KB

	chromeapp-keydown.mp4 732 KB View Download

Updated screen recording with monitorEvents(window, "keydown") as requested.

Deleted: chromeapp-keydown2.mp4 854 KB

	chromeapp-keydown2.mp4 854 KB View Download

Oh see I see the misunderstanding now...

You are expecting the keydown inside the chrome-extension:// window.

Bisected to change: https://chromium.googlesource.com/chromium/src/+/3131414035a033d1fb624913474dbdac04158198

Expect that this is working as intended because the origin of the two documents is different. Over to lfg@ to comment.

Thanks for triaging, Dave. This is working as intended. A bit of context: before the refactor on GuestViews to use the RenderFrame architecture, we used a plugin to embed the webview, and the plugin relied on event forwarding from one process to another. A side effect of this is that the event listeners would fire on the parent, as well as the child. We've always considered this a bug.

Now we are only firing event listeners on the focused frame, which means that the parent will not receive the input events.

If you need the input events in the parent, the supported way achieve this is to use the script injection APIs to inject code that forwards the events via the postMessage API.

The NextAction date has arrived: 2018-01-25

I don't understand this.

If the webview doesn't get the key input events, how can it post them back to the parent?

Do injected scripts get some extra system level view?

If the webview is focused, then it will get the key inputs.

Otherwise they would presumably being going to the parent anyways, and can be handled there in the usual way.

The key events are going to the webview. What this bug is about is that with the new architecture you aren't seeing the keypress events in the page that embeds the webview (the parent).

lfg & wjmaclean are advocating that you add script to your webview page that then posts the key events back to the embedding page.