Adding M-62 label, since as-per 774568, I first noticed this in M62.

weidongg@ please triage.
wez@ we handle caps locks changes on release. Can you please explain why this is important to you to help us prioritize.

I think the key up event is consumed in accelerator [1], because caps lock toggling is now handled on key release. This does not only happen for caps lock key. If you hit other accelerators such as Alt+'[', or ctrl+alt+h, you would find key event triggering the corresponding action disappear.

From event rewriter comment [2], it seems it is expected that F16 is handled in the same way as Caps Lock key.

[1] https://cs.chromium.org/chromium/src/ash/accelerators/accelerator_controller.cc?q=accelerator_controller&dr=C&l=679
[2] https://cs.chromium.org/chromium/src/ui/chromeos/events/event_rewriter_chromeos.cc?q=EventRewriterCh&sq=package:chromium&dr=CSs&l=715

Re #4: This appears to break CapsLock over Chrome Remote Desktop from a ChromeOS device.

Re #5: OK, so it sounds like we just need to fix the accelerator not to consume the 'keyup' event so it can propagate correctly to content? Regardless of whether F16 is treated the same way as CapsLock by the rewriter, we shouldn't be propagating CapsLock events to web content that have |key| set to "F16" rather than "CapsLock".

 Issue 774568  has been merged into this issue.

 Issue 737029  has been merged into this issue.

Bumping priority & punting back to triage since this is a regression from the DOM-specified behaviour, and breaks CapsLock in Chromoting & similar apps.

 Issue 759157  has been merged into this issue.

Weidongg is already investigating a solution.

Thanks afakhry@ for helping debuging this bug. As an accelerator key, caps lock is handled and stops propagation in either [1] or [2] before it is sent to web app or browser tab. One solution is to keep current caps lock behavior and moves its handling back to event_rewriter_chromeos.cc. Here is the CL for this solution:
https://chromium-review.googlesource.com/c/chromium/src/+/740090

[1] https://cs.chromium.org/chromium/src/ui/views/focus/focus_manager.cc?q=focus_manager&sq=package:chromium&dr=C&l=101
[2] https://cs.chromium.org/chromium/src/chrome/browser/ui/views/frame/browser_view.cc?q=browser_view.cc&sq=package:chromium&dr&l=1360

Re #6, the DomKey F16 should be remapped to DomKey CapsLock in event rewriter [1], but later it seems to be somehow changed back to F16. Still investigating the reason causing this.

[1] https://cs.chromium.org/chromium/src/ui/chromeos/events/event_rewriter_chromeos.cc?q=event_rewriter_chromeos.cc&dr&l=94

The DomKey F16 is first mapped to CapsLock, then in [1] the CapsLock is changed back to F16 when extracting layout results. I took a deeper look and found that the |xkb_keysym| for the key is XKB_KEY_XF86Launch7 in [2] and then converted to F16. Is this intended behavior, should we change this?

[1] https://cs.chromium.org/chromium/src/ui/chromeos/events/event_rewriter_chromeos.cc?q=event_rewriter_chromeos.cc&dr&l=233
[2] https://cs.chromium.org/chromium/src/ui/events/ozone/layout/xkb/xkb_keyboard_layout_engine.cc?q=xkb_keyboard_la&dr=C&l=751

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

commit 9b39004efe5a98788beeffb5c395522f3b31b2a4
Author: Weidong Guo <weidongg@chromium.org>
Date: Sun Oct 29 19:07:43 2017

Fix caps lock key only having key down event

Changes:
Move caps lock key handling from accelerator controller to
event_rewriter_chromeos.cc. As an accelerator key, caps lock is always
consumed before it is sent to web app (e.g. CRD) or browser tab
(keyboard event viewer). So we handle it in event rewriter and do not
stop propagating it.

BUG= 775743 

Change-Id: Ib3eb29cb4be023142b0d402d7c56015a7197bc14
Reviewed-on: https://chromium-review.googlesource.com/740090
Reviewed-by: Wez <wez@chromium.org>
Reviewed-by: Shu Chen <shuchen@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Commit-Queue: Weidong Guo <weidongg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512420}
[modify] https://crrev.com/9b39004efe5a98788beeffb5c395522f3b31b2a4/ash/accelerators/accelerator_controller.cc
[modify] https://crrev.com/9b39004efe5a98788beeffb5c395522f3b31b2a4/ash/accelerators/accelerator_controller_unittest.cc
[modify] https://crrev.com/9b39004efe5a98788beeffb5c395522f3b31b2a4/ash/accelerators/accelerator_table.cc
[modify] https://crrev.com/9b39004efe5a98788beeffb5c395522f3b31b2a4/ash/accelerators/accelerator_table_unittest.cc
[modify] https://crrev.com/9b39004efe5a98788beeffb5c395522f3b31b2a4/chrome/browser/chromeos/events/event_rewriter_unittest.cc
[modify] https://crrev.com/9b39004efe5a98788beeffb5c395522f3b31b2a4/ui/base/ime/input_method_chromeos.cc
[modify] https://crrev.com/9b39004efe5a98788beeffb5c395522f3b31b2a4/ui/chromeos/events/event_rewriter_chromeos.cc

Issue 808378 has been merged into this issue.

The mis-reporting of CapsLock as F16 still seems to be present, so I've filed issue 810635 and assigned it to you, Weidong.

In #14, I analyzed the reason for this bug and not sure whether this is WAI. But it seems to be no, because we have test case for this and failed to detect the problem due to different code path between device and testing. I replied in the issue 810635, Thanks.