What do you see if you try the same keyboard shortcut using F3 on http://w3c.github.io/uievents/tools/key-event-viewer.html (F4 will close the tab, since this isn't an app)? For R58, I see keydowns for Ctrl, Meta and F3, followed by the corresponding keyup events.

The page refreshes once I press F3 (I guess that would be expected in my failure case).

I've attached a screenshot when I try the same sequence with F2 (forward, but since it can't go forward it does nothing)

Deleted: Screenshot 2017-05-31 at 13.58.35.png 290 KB

	Screenshot 2017-05-31 at 13.58.35.png 290 KB View Download

This looks like a regression (or at least a change in behaviour) with regards to whether or not web content can override these keys. Given that it also affects apps, I suspect it's unintentional, but I don't know what efforts are ongoing in that area. The F2 example is interesting--it suggests that not only are neither BrowserForward nor F2 received by the web page, but that the keyup events for Ctrl and Meta are also lost.

The fullscreen and overview buttons are system keys and hence they're always consumed by the OS (unless they were rewritten to F4 and F5 respectively using the Search key).

Can you please check your keyboard settings? In particular the "Treat top-row keys as function keys" setting?

weidongg@, can you please take a look at the Search+<top-row-keys> logic in the EventRewriter? Any regressions there?

Yes, I use the search key to change them into their function key equivalents.

"Treat top-row keys as function keys" is unchecked.

Deleted: Screenshot 2017-06-07 at 09.44.28.png 112 KB

	Screenshot 2017-06-07 at 09.44.28.png 112 KB View Download

Oh hmm, now I'm not so sure... If I check that option and then use the number row, it works just fine. But now, I honestly can't remember if I used the number row or the function key row. It was probably the number key row.

Is it possible that this flag flipped in M60? (enabled by default -> disabled by default)

The flag used to be disabled by default as well.

On 59, it seems to work without that that flag enabled.

If the flag is disabled, 'search key + top row' or 'search key + num row' will become function keys (F1, F2, etc.).
If the flag is enabled, top row will become function keys without holding search key. And 'search key +top row key' will go back to system keys.

I did the following test in M60 with the flag disabled (default).
1. Map ESC to Search in chrome os.
2. Chromoting from linux (client) to chrome os (host).
3. Hold CTRL+ESC and tap F4 in linux.
Result: the browser tab is closed.

I think this is as expected.

I think the link in c#1 should be a good repro.

My screenshot in c#2 shows what happens when I press right_ctrl+search+forward arrow(F2) on M60. F2 doesn't come through and the key ups are lost. 

I did the same thing on M59, but the F2 key comes through and the key ups are registered. You can ignore the extra control key down since that's when I was taking the screenshot. Note that 'treat top row function keys' is unchecked in both cases.

(1) Open chrome remote desktop with i3wm running on linux.
Are you chromoting from linux(client) to chrome os(host)?
(2) Bind Mod4+F4 to switch to workspace 4.
By mod4, do you mean the window key in linux, which is mapped to search key in chromeos?
(3) Set "Use right ctrl for Win key".
Do you set this mapping in linux, or do you set 'Ctrl->Search key' in chrome os?
(4) Press right_ctrl+search+F4 (full screen key)
Do you press these keys in linux? If so, does 'search key' mean the right ctrl or windows key?

1) No the other way around. chromoting from my chromebook to my linux desktop.
2) Yes, Mod4 is the "windows" key.
3) This setting is in chrome remote desktop on the chrome OS side. (It's in the hamburger menu on the top left of the window.)
4) I press these on my chromebook. So search, is the chrome OS search key.

Hey, I could repro this bug. right_ctrl in chrome os keyboard has such problem, but left_ctrl has no such problem. I used http://w3c.github.io/uievents/tools/key-event-viewer.html to test the right_ctrl. If you open the URL in chrome os, the right_ctrl shows ControlRight. If you open the URL in linux and tap the right_ctrl in chrome os, it shows MetaRight.

I also test it when chromoting from chrome os to macbook. No such problem exists. The right_ctrl shows ControlRight.

Conclusion: It seems to me that it's not Chrome OS's issue. It seems that the CRD host in linux maps right_ctrl to MetaRight.

jamiewalch@, could you please confirm this?
 

CRD does indeed map the right Ctrl key to the right Meta key, but that's not the issue--comments 1-3 give a repro that doesn't involve CRD. This is a change in behaviour between R58 and R60 which may or may not be intentional. I would say that the behaviour I highlighted in #3 is a bug because it leads to apps receiving a keydown event with no corresponding keyup.

Re #16,     
Aha, I tried 'Search key + Forward key' which should be mapped to F2 key, but the key event viewer still shows Forward key. This is because one CL make the key event go through event rewriter twice, which maps the Forward key back to itself. (Refer to crbug.com/727711)
Fortunately this bug has been fixed, I build from ToT, such problem has been fixed as well.

So the symptom here has the same root cause as bug 727711, correct?  If so we should close this as a duplicate.

Re #18, yes, you are right. I believe it has the same root cause.