Steps to reproduce: 1. Visit <https://w3c.github.io/uievents/tools/key-event-viewer.html> 2. Focus the text field 3. Press Command + . Then you see a key down and key press with key Escape, but code Period 😃. (Also keyup is missing, but that’s “expected” because it was generated from a key command. I put “expected” in quotes, because I’m kinda leaning towards fixing that in UIKit just for Escape).
<rdar://problem/52498001>
There's a few ways I could go about with this bug: 1. Do what I originally complained about: fix the key code of the dispatched event to be Escape instead of Period. 2. Take this opportunity to re-evaluate this whole Command + . business: maybe the experience should match the experience when typing a Roman variant (e.g. Option + 2 == ™) => this dispatches (looking at key codes): keydown Option, keydown 2, keypress ™, keyup 2, keyup Option. The benefit of (2) is that a web app could still know about Command + . and have their own handling. But how many web apps would even care about this? I know of 0 web apps that have their own Command + . handling and it's such an esoteric Mac/iOS key command that I kinda doubt a web app would unless that app is targeted at such platforms or embedded in a native app on those platforms. Another downside is that it reveals an implementation detail and we don't reveal such a detail to native apps on iOS..... Lastly, if we do (1) and a developer really wants to distinguish between Escape and Command + . they still can! They just have to do a little bit more work and track keydown, keyup Command whenever they see a keydown/keypress of Escape. So, I'm leaning towards doing (1).
Created attachment 373515 [details] Patch
Created attachment 373516 [details] Patch
Comment on attachment 373516 [details] Patch Clearing flags on attachment: 373516 Committed r247232: <https://trac.webkit.org/changeset/247232>
All reviewed patches have been landed. Closing bug.