Bug 189898

Summary: Separate Mac and iOS implementation of windowsKeyCodeForCharCode()
Product: WebKit Reporter: Daniel Bates <dbates>
Component: WebCore Misc.Assignee: Daniel Bates <dbates>
Status: RESOLVED FIXED    
Severity: Normal CC: thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Local Build   
Hardware: iPhone / iPad   
OS: iOS 11   
Bug Depends on:    
Bug Blocks: 190571    
Attachments:
Description Flags
Patch
none
Patch thorton: review+

Description Daniel Bates 2018-09-23 15:01:38 PDT
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.
Comment 1 Daniel Bates 2018-09-23 15:21:04 PDT
Created attachment 350591 [details]
Patch
Comment 2 Daniel Bates 2018-09-24 12:20:25 PDT
Created attachment 350662 [details]
Patch
Comment 3 Daniel Bates 2018-09-24 12:21:27 PDT
Comment on attachment 350662 [details]
Patch

Rebased patch following the landing of the patch for bug #189604.
Comment 4 Tim Horton 2018-09-24 12:29:51 PDT
Comment on attachment 350662 [details]
Patch

This is kind of weirdly the opposite direction I would usually go but it seems ok.
Comment 5 Daniel Bates 2018-09-24 12:31:37 PDT
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>
Comment 6 Daniel Bates 2018-09-24 13:47:47 PDT
Committed r236427: <https://trac.webkit.org/changeset/236427>
Comment 7 Radar WebKit Bug Importer 2018-09-24 13:48:23 PDT
<rdar://problem/44738357>
Comment 8 Daniel Bates 2018-09-25 10:20:55 PDT
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.