Currently Mac and iOS share the same base implementation of windowsKeyCodeForCharCode() that is modified at compile-time depending on whether we are building for Mac and iOS.
Created attachment 350591 [details] Patch
Created attachment 350662 [details] Patch
Comment on attachment 350662 [details] Patch Rebased patch following the landing of the patch for bug #189604.
Comment on attachment 350662 [details] Patch This is kind of weirdly the opposite direction I would usually go but it seems ok.
The motivation of this patch is to clean up the Mac and iOS char code to Windows virtual key code. This is a step towards teaching the keyboard code how to map various special non-visible keys on iOS [1]. [1] <https://developer.apple.com/documentation/uikit/uikeycommand/input_strings_for_special_keys?changes=_2&language=objc>
Committed r236427: <https://trac.webkit.org/changeset/236427>
<rdar://problem/44738357>
Comment on attachment 350662 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=350662&action=review > Source/WebCore/ChangeLog:12 > + Mac and iOS have significant differences in how they represent function keys. It is not worthwhile > + to share windowsKeyCodeForCharCode() between them given these differences. On Mac function keys The primary reason windowsKeyCodeForCharCode() was shared was to support testing using window.eventSender in iOS DRT of special keys (e.g. F1) as we also shared much of the window.eventSender machinery for Mac and iOS. We have not been running DRT for iOS on build.webkit.org or EWS for at least a year now :( The lack of iOS DRT bots to catch regressions is another reason why it is not worthwhile to continue sharing windowsKeyCodeForCharCode(). We may want to consider removing the iOS DRT code as it is currently bit rotting.