E.g., Ctrl + A shouldn't fire keypress on macOS
Reported by
dtoybo...@gmail.com,
May 25 2018
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Steps to reproduce the problem: 1. Load https://w3c.github.io/uievents/tools/key-event-viewer.html 2. Move focus to the <input> 3. Type control + A on macOS 4. Type control + option + A on macOS 5. Check the "Read only" checkbox 6. Type control + A on macOS 7. Type control + option + A on macOS What is the expected behavior? At #3, #4, #6, #7, keypress events won't be fired since keypress events should be fired "f and only if that key normally produces a character value". https://www.w3.org/TR/uievents/#event-type-keypress What went wrong? #3 does not fire keypress event (as expected) #4 fires keypress event whose charCode is 1 (invalid) #6 fires keypress event whose charCode is 1 (invalid) #7 fires keypress event whose charCode is 1 (invalid) Did this work before? N/A Chrome version: 66.0.3359.139 Channel: stable OS Version: OS X 10.13.4 Flash Version: Firefox will stop dispatching those keypress events since Google requested to us. Safari also has same bug.
,
May 25 2018
Able to reproduce the issue on chrome reported version 66.0.3359.139, latest stable 66.0.3359.181 and on latest chrome# 68.0.3438.0 using Mac 10.12.6. As this issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriage. Note: This issue is specific to Mac. Thanks!
,
May 25 2018
Triage: Routing to Blink > Input.
,
May 31 2018
nzolghadr@ PTAL
,
Aug 2
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by krajshree@chromium.org
, May 25 2018