COMMIT_MESSAGE

[iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element
 
https://bugs.webkit.org/show_bug.cgi?id=192824

<rdar://problem/47100332>

Reviewed by Wenson Hsieh.

Source/WebCore:

When building with USE(UIKIT_KEYBOARD_ADDITIONS) enabled, normalize input strings for some more key codes

now that hardware key events to non-editable elements use the same code path as for editable elements.

* platform/ios/KeyEventIOS.mm:

(WebCore::windowsKeyCodeForCharCode): Demarcate mappings that are only needed when building with

!USE(UIKIT_KEYBOARD_ADDITIONS) in the hope that one day we can remove this code.

(WebCore::isFunctionKey): Ditto.

* platform/ios/WebEvent.mm:

(normalizedStringWithAppKitCompatibilityMapping): Normalize some more input strings when building with

USE(UIKIT_KEYBOARD_ADDITIONS) enabled.

Source/WebCore/PAL:

Expose more enumerators.

* pal/spi/cocoa/IOKitSPI.h:

Source/WebKit:

Use the same code path for key events to editable elements and non-editable elements.

Currently we have different code paths for hardware key events depending on whether the active element

is editable or non-editable. Historically to support dispatching DOM keyboard events for hardware key

presses this differentiation was a necessary workaround for UIKit's event processing precedence of

interpreting key events for system text editing commands and app commands before dispatching unhandled

key events to WebKit. This workaround intercepted raw key UIEvents and manually reconstructed a

WebEvent from it. However there is not enough information in an UIEvent to reconstruct a WebEvent that

is identical to the WebEvent that UIKit would have dispatched. In particular, keyup UIEvents always have

empty modified and unmodified input strings. The UIKit keyboard machinery maintains additional state

that is necessary to manufacture the correct WebEvent corresponding to a UIEvent.

As a side benefit of this change, with the exception of modifier flag changes, both hardware and software

key events use the same code path.

* UIProcess/ios/WKContentViewInteraction.h:

* UIProcess/ios/WKContentViewInteraction.mm:

(-[WKContentView _disableAutomaticKeyboardUI]): Implement UIKit SPI to prevent showing the keyboard UI

when there is no focused element now that we are no longer intercepting key UIEvents. Formerly the

keyboard UI was disabled as a side effect of not becoming first responder when there was no focused

element (by returning NO in -_requiresKeyboardWhenFirstResponder).

(-[WKContentView _requiresKeyboardWhenFirstResponder]): Return YES when there is no focused element.

(-[WKContentView textInputTraits]): Do not update traits when the keyboard is going to be dismissed

now that we require a keyboard when first responder even if the focused element is non-editable.

(-[WKContentView _didHandleKeyEvent:eventWasHandled:]): Skip logic for re-sending UIEvents to UIKit

as UIKit now processes the event first. This logic was necessary in order to finally allow UIKit

its chance to interpret the UIEvent, we intercepted, for app key commands.

Tools:

Fix a bug where the wrong usage code was used for F13 thru F24.

* WebKitTestRunner/ios/HIDEventGenerator.mm:

(keyCodeForDOMFunctionKey):

LayoutTests:

Update tests and expected results. As it turns out fixing the bug in WebKitTestRunner/ios/HIDEventGenerator.mm

so that we now dispatch key events for F17 thru F24 exposed a bug in UIKit. See <rdar://problem/47128940>.

This same bug is also responsible for a lack of key events when the Insert key is pressed.

Added sub-test for Tab key to keypress-keys-in-non-editable-element.html. Changed expected result in test

keypress-keys-in-non-editable-element.html for the forward delete key to expect failure. We expect that pressing

the forward delete key will not dispatch a keypress to match the behavior on Mac. This will be addressed by a

UIKit fix.

* fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt:

* fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html:

* fast/events/ios/keypress-keys-in-non-editable-element-expected.txt:

* fast/events/ios/keypress-keys-in-non-editable-element.html:

LayoutTests/ChangeLog

2019-01-11  Daniel Bates  <dabates@apple.com>

        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element

        https://bugs.webkit.org/show_bug.cgi?id=192824

        <rdar://problem/47100332>

        Reviewed by Wenson Hsieh.

        Update tests and expected results. As it turns out fixing the bug in WebKitTestRunner/ios/HIDEventGenerator.mm

        so that we now dispatch key events for F17 thru F24 exposed a bug in UIKit. See <rdar://problem/47128940>.

        This same bug is also responsible for a lack of key events when the Insert key is pressed.

        Added sub-test for Tab key to keypress-keys-in-non-editable-element.html. Changed expected result in test

        keypress-keys-in-non-editable-element.html for the forward delete key to expect failure. We expect that pressing

        the forward delete key will not dispatch a keypress to match the behavior on Mac. This will be addressed by a

        UIKit fix.

        * fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt:

        * fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html:

        * fast/events/ios/keypress-keys-in-non-editable-element-expected.txt:

        * fast/events/ios/keypress-keys-in-non-editable-element.html:

2018-12-05  Daniel Bates  <dabates@apple.com>

        [iOS] Add test to ensure that a web page can prevent the default for Command + A

LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt

1 This tests that DOM keydown and keyup events are dispatched to a non-editable <body> on iOS when pressing special keys on a hardware keyboard. To run this test manually, verify that two messages are emitted when you press the following keys: ↑, ↓, ←, →, Delete, End, Enter, Escape, Home~~, Insert~~, left Alt, left ⌘ Command, left Ctrl, left ⇧ Shift, Page Down, Page Up, Return, right Alt, right ⌘ Command, right Ctrl, right ⇧ Shift, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16~~, F17, F18, F19, F20, F21, F22, F23, F24~~.

1This tests that DOM keydown and keyup events are dispatched to a non-editable <body> on iOS when pressing special keys on a hardware keyboard. To run this test manually, verify that two messages are emitted when you press the following keys: Tab, ↑, ↓, ←, →, Delete, End, Enter, Escape, Home, left Alt, left ⌘ Command, left Ctrl, left ⇧ Shift, Page Down, Page Up, Return, right Alt, right ⌘ Command, right Ctrl, right ⇧ Shift, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16.

22

3type: keydown, key: Tab, code: Tab, keyIdentifier: U+0009, keyCode: 9, charCode: 0, keyCode: 9, which: 9

4type: keyup, key: Dead, code: Tab, keyIdentifier: Unidentified, keyCode: 9, charCode: 0, keyCode: 9, which: 9

type: keydown, key: ArrowUp, code: ArrowUp, keyIdentifier: Up, keyCode: 38, charCode: 0, keyCode: 38, which: 38

type: keyup, key: ArrowUp, code: ArrowUp, keyIdentifier: Up, keyCode: 38, charCode: 0, keyCode: 38, which: 38

type: keydown, key: ArrowDown, code: ArrowDown, keyIdentifier: Down, keyCode: 40, charCode: 0, keyCode: 40, which: 40

LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html

@@if (window.testRunner) {

</script>

</head>

<body onkeydown="handleKeyDown(event)" onkeyup="handleKeyUp(event)">

15 <p>This tests that DOM keydown and keyup events are dispatched to a non-editable <body> on iOS when pressing special keys on a hardware keyboard. To run this test manually, verify that two messages are emitted when you press the following keys: <kbd>↑</kbd>, <kbd>↓</kbd>, <kbd>←</kbd>, <kbd>→</kbd>, <kbd>Delete</kbd>, <kbd>End</kbd>, <kbd>Enter</kbd>, <kbd>Escape</kbd>, <kbd>Home</kbd>, <kbd>Insert</kbd>, left <kbd>Alt</kbd>, left <kbd>⌘ Command</kbd>, left <kbd>Ctrl</kbd>, left <kbd>⇧ Shift</kbd>, <kbd>Page Down</kbd>, <kbd>Page Up</kbd>, <kbd>Return</kbd>, right <kbd>Alt</kbd>, right <kbd>⌘ Command</kbd>, right <kbd>Ctrl</kbd>, right <kbd>⇧ Shift</kbd>, <kbd>F1</kbd>, <kbd>F2</kbd>, <kbd>F3</kbd>, <kbd>F4</kbd>, <kbd>F5</kbd>, <kbd>F6</kbd>, <kbd>F7</kbd>, <kbd>F8</kbd>, <kbd>F9</kbd>, <kbd>F10</kbd>, <kbd>F11</kbd>, <kbd>F12</kbd>, <kbd>F13</kbd>, <kbd>F14</kbd>, <kbd>F15</kbd>, <kbd>F16</kbd>, <kbd>F17</kbd>, <kbd>F18</kbd>, <kbd>F19</kbd>, <kbd>F20</kbd>, <kbd>F21</kbd>, <kbd>F22</kbd>, <kbd>F23</kbd>, <kbd>F24</kbd>.

15<p>This tests that DOM keydown and keyup events are dispatched to a non-editable <body> on iOS when pressing special keys on a hardware keyboard. To run this test manually, verify that two messages are emitted when you press the following keys: <kbd>Tab</kbd>, <kbd>↑</kbd>, <kbd>↓</kbd>, <kbd>←</kbd>, <kbd>→</kbd>, <kbd>Delete</kbd>, <kbd>End</kbd>, <kbd>Enter</kbd>, <kbd>Escape</kbd>, <kbd>Home</kbd>, left <kbd>Alt</kbd>, left <kbd>⌘ Command</kbd>, left <kbd>Ctrl</kbd>, left <kbd>⇧ Shift</kbd>, <kbd>Page Down</kbd>, <kbd>Page Up</kbd>, <kbd>Return</kbd>, right <kbd>Alt</kbd>, right <kbd>⌘ Command</kbd>, right <kbd>Ctrl</kbd>, right <kbd>⇧ Shift</kbd>, <kbd>F1</kbd>, <kbd>F2</kbd>, <kbd>F3</kbd>, <kbd>F4</kbd>, <kbd>F5</kbd>, <kbd>F6</kbd>, <kbd>F7</kbd>, <kbd>F8</kbd>, <kbd>F9</kbd>, <kbd>F10</kbd>, <kbd>F11</kbd>, <kbd>F12</kbd>, <kbd>F13</kbd>, <kbd>F14</kbd>, <kbd>F15</kbd>, <kbd>F16</kbd>.

</p>

<pre id="console"></pre>

<script>

var remainingKeysToPress = [

20 "\t",

    "upArrow",

    "downArrow",

    "leftArrow",

@@var remainingKeysToPress = [

    "enter",

    "escape",

    "home",

29 "insert",

30 // FIXME: Add "insert" once <rdar://problem/47128940> is fixed.

    "leftAlt",

    "leftCommand",

    "leftControl",

@@var remainingKeysToPress = [

    "rightShift",

];

43 for (let i = 1; i <= 24; ++i)

44// FIXME: Check function keys up to F24 once <rdar://problem/47128940> is fixed.

45for (let i = 1; i <= 16; ++i)

    remainingKeysToPress.push("F" + i);

async function nextKeyPress()

LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element-expected.txt

@@PASS delete did dispatch a keypress event.

PASS enter did dispatch a keypress event.

PASS escape did dispatch a keypress event.

PASS return did dispatch a keypress event.

57 P~~ASS~~ forwardDelete ~~did~~ dispatch a keypress event.

57FAIL forwardDelete should not have dispatched a keypress event. It did dispatch one.

PASS upArrow did not dispatch a keypress event.

PASS downArrow did not dispatch a keypress event.

PASS leftArrow did not dispatch a keypress event.

@@PASS F13 did not dispatch a keypress event.

PASS F14 did not dispatch a keypress event.

PASS F15 did not dispatch a keypress event.

PASS F16 did not dispatch a keypress event.

PASS F17 did not dispatch a keypress event.

PASS F18 did not dispatch a keypress event.

PASS F19 did not dispatch a keypress event.

PASS F20 did not dispatch a keypress event.

PASS F21 did not dispatch a keypress event.

PASS F22 did not dispatch a keypress event.

PASS F23 did not dispatch a keypress event.

PASS F24 did not dispatch a keypress event.

PASS successfullyParsed is true

TEST COMPLETE

LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element.html

@@tests.push(new TestKeyPressDispatchedFor("enter"));

tests.push(new TestKeyPressDispatchedFor("escape"));

tests.push(new TestKeyPressDispatchedFor("return"));

// The forward delete key is mapped to the delete key on iOS and dispatches a keypress event.

// On Mac it is treated as its own key and does not dispatch a keypress event.

tests.push(new TestKeyPressDispatchedFor("forwardDelete"));

4844// Special keys: KeyPress should not be dispatched.

45tests.push(new TestKeyPressNotDispatchedFor("forwardDelete"));

tests.push(new TestKeyPressNotDispatchedFor("upArrow"));

tests.push(new TestKeyPressNotDispatchedFor("downArrow"));

tests.push(new TestKeyPressNotDispatchedFor("leftArrow"));

@@tests.push(new TestKeyPressNotDispatchedFor("rightArrow"));

tests.push(new TestKeyPressNotDispatchedFor("clear"));

tests.push(new TestKeyPressNotDispatchedFor("end"));

tests.push(new TestKeyPressNotDispatchedFor("home"));

56 ~~tests.push(new~~ TestK~~eyP~~ressN~~otD~~ispatchedF~~or(~~"insert"~~));~~

53// FIXME: Test that keypress is not dispatched for "insert" once <rdar://problem/47128940> is fixed.

tests.push(new TestKeyPressNotDispatchedFor("leftAlt"));

tests.push(new TestKeyPressNotDispatchedFor("leftCommand"));

tests.push(new TestKeyPressNotDispatchedFor("leftControl"));

@@tests.push(new TestKeyPressNotDispatchedFor("rightAlt"));

tests.push(new TestKeyPressNotDispatchedFor("rightCommand"));

tests.push(new TestKeyPressNotDispatchedFor("rightControl"));

tests.push(new TestKeyPressNotDispatchedFor("rightShift"));

67 for (let i = 1; i <= 24; ++i)

64// FIXME: Check function keys up to F24 once <rdar://problem/47128940> is fixed.

65for (let i = 1; i <= 16; ++i)

    tests.push(new TestKeyPressNotDispatchedFor("F" + i));

function nextKeyPress()

Source/WebCore/ChangeLog

2019-01-11  Daniel Bates  <dabates@apple.com>

        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element

        https://bugs.webkit.org/show_bug.cgi?id=192824

        <rdar://problem/47100332>

        Reviewed by Wenson Hsieh.

        When building with USE(UIKIT_KEYBOARD_ADDITIONS) enabled, normalize input strings for some more key codes

        now that hardware key events to non-editable elements use the same code path as for editable elements. 

        * platform/ios/KeyEventIOS.mm:

        (WebCore::windowsKeyCodeForCharCode): Demarcate mappings that are only needed when building with

        !USE(UIKIT_KEYBOARD_ADDITIONS) in the hope that one day we can remove this code.

        (WebCore::isFunctionKey): Ditto.

        * platform/ios/WebEvent.mm:

        (normalizedStringWithAppKitCompatibilityMapping): Normalize some more input strings when building with

        USE(UIKIT_KEYBOARD_ADDITIONS) enabled.

2019-01-15  Chris Dumez  <cdumez@apple.com>

        Regression(PSON) View becomes blank after click a cross-site download link

Source/WebCore/PAL/ChangeLog

2019-01-11  Daniel Bates  <dabates@apple.com>

        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element

        https://bugs.webkit.org/show_bug.cgi?id=192824

        <rdar://problem/47100332>

        Reviewed by Wenson Hsieh.

        Expose more enumerators.

        * pal/spi/cocoa/IOKitSPI.h:

2019-01-14  Commit Queue  <commit-queue@webkit.org>

        Unreviewed, rolling out r239901, r239909, r239910, r239912,

Source/WebCore/PAL/pal/spi/cocoa/IOKitSPI.h

@@enum {

    kHIDUsage_KeyboardSlash = 0x38,

    kHIDUsage_KeyboardCapsLock = 0x39,

    kHIDUsage_KeyboardF1 = 0x3A,

188 kHIDUsage_KeyboardF12 = 0x45,

    kHIDUsage_KeyboardPrintScreen = 0x46,

    kHIDUsage_KeyboardInsert = 0x49,

    kHIDUsage_KeyboardHome = 0x4A,

@@enum {

    kHIDUsage_KeyboardUpArrow = 0x52,

    kHIDUsage_KeypadNumLock = 0x53,

    kHIDUsage_KeyboardF13 = 0x68,

202 kHIDUsage_KeyboardF24 = 0x73,

    kHIDUsage_KeyboardMenu = 0x76,

    kHIDUsage_KeyboardLeftControl = 0xE0,

    kHIDUsage_KeyboardLeftShift = 0xE1,

Source/WebCore/platform/ios/KeyEventIOS.mm

@@int windowsKeyCodeForKeyCode(uint16_t keyCode)

    return 0; // Unknown key

}

// This function is only used to map software keyboard events because they lack a key code.

// When !USE(UIKIT_KEYBOARD_ADDITIONS), this function is also used to map hardware keyboard

// keyup events because they lack a key code.

int windowsKeyCodeForCharCode(unichar charCode)

{

    switch (charCode) {

    case 8: case 0x7F: return VK_BACK;

    case 9: return VK_TAB;

    case 0xD: case 3: return VK_RETURN;

208 case 0x1B: return VK_ESCAPE; // WebKit generated code for Escape.

    case ' ': return VK_SPACE;

    case '0': case ')': return VK_0;

@@int windowsKeyCodeForCharCode(unichar charCode)

    case 'y': case 'Y': return VK_Y;

    case 'z': case 'Z': return VK_Z;

#if !USE(UIKIT_KEYBOARD_ADDITIONS)

    case 0x1B: return VK_ESCAPE; // WebKit generated code for Escape.

    // WebKit uses Unicode PUA codes in the OpenStep reserve range for some special keys.

    case NSUpArrowFunctionKey: return VK_UP;

    case NSDownArrowFunctionKey: return VK_DOWN;

@@int windowsKeyCodeForCharCode(unichar charCode)

    case NSRightArrowFunctionKey: return VK_RIGHT;

    case NSPageUpFunctionKey: return VK_PRIOR;

    case NSPageDownFunctionKey: return VK_NEXT;

260#endif

    // This is for U.S. keyboard mapping, and doesn't necessarily make sense for different keyboard layouts.

    // For example, '"' on Windows Russian layout is VK_2, not VK_OEM_7.

@@int windowsKeyCodeForCharCode(unichar charCode)

static bool isFunctionKey(UChar charCode)

{

    switch (charCode) {

282#if !USE(UIKIT_KEYBOARD_ADDITIONS)

    case 1: // Home

    case 4: // End

    case 5: // FIXME: For some reason WebKitTestRunner generates this code for F14 (why?).

    case 0x7F: // Forward Delete

    case 0x10: // Function key (e.g. F1, F2, ...)

288#endif

    // WebKit uses Unicode PUA codes in the OpenStep reserve range for some special keys.

    case NSUpArrowFunctionKey:

@@static bool isFunctionKey(UChar charCode)

    case NSPageUpFunctionKey:

    case NSPageDownFunctionKey:

    case NSClearLineFunctionKey: // Num Lock / Clear

#if USE(UIKIT_KEYBOARD_ADDITIONS)

    case NSDeleteFunctionKey: // Forward delete

    case NSEndFunctionKey:

    case NSInsertFunctionKey:

    case NSHomeFunctionKey:

#endif

290304 return true;

291305 }

#if USE(UIKIT_KEYBOARD_ADDITIONS)

    if (charCode >= NSF1FunctionKey && charCode <= NSF24FunctionKey)

        return true;

#endif

    return false;

}

Source/WebCore/platform/ios/WebEvent.mm

@@static NSString *normalizedStringWithAppKitCompatibilityMapping(NSString *charac

        return @"\x1B";

    case kHIDUsage_KeypadNumLock: // Num Lock / Clear

        return makeNSStringWithCharacter(NSClearLineFunctionKey);

#if USE(UIKIT_KEYBOARD_ADDITIONS)

    case kHIDUsage_KeyboardDeleteForward:

        return makeNSStringWithCharacter(NSDeleteFunctionKey);

    case kHIDUsage_KeyboardEnd:

        return makeNSStringWithCharacter(NSEndFunctionKey);

    case kHIDUsage_KeyboardInsert:

        return makeNSStringWithCharacter(NSInsertFunctionKey);

    case kHIDUsage_KeyboardHome:

        return makeNSStringWithCharacter(NSHomeFunctionKey);

#endif

156166 }

#if USE(UIKIT_KEYBOARD_ADDITIONS)

    if (keyCode >= kHIDUsage_KeyboardF1 && keyCode <= kHIDUsage_KeyboardF12)

        return makeNSStringWithCharacter(NSF1FunctionKey + (keyCode - kHIDUsage_KeyboardF1));

    if (keyCode >= kHIDUsage_KeyboardF13 && keyCode <= kHIDUsage_KeyboardF24)

        return makeNSStringWithCharacter(NSF13FunctionKey + (keyCode - kHIDUsage_KeyboardF13));

#endif

    return characters;

}

Source/WebKit/ChangeLog

2019-01-11  Daniel Bates  <dabates@apple.com>

        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element

        https://bugs.webkit.org/show_bug.cgi?id=192824

        <rdar://problem/47100332>

        Reviewed by Wenson Hsieh.

        Use the same code path for key events to editable elements and non-editable elements.

        Currently we have different code paths for hardware key events depending on whether the active element

        is editable or non-editable. Historically to support dispatching DOM keyboard events for hardware key

        presses this differentiation was a necessary workaround for UIKit's event processing precedence of

        interpreting key events for system text editing commands and app commands before dispatching unhandled

        key events to WebKit. This workaround intercepted raw key UIEvents and manually reconstructed a

        WebEvent from it. However there is not enough information in an UIEvent to reconstruct a WebEvent that

        is identical to the WebEvent that UIKit would have dispatched. In particular, keyup UIEvents always have

        empty modified and unmodified input strings. The UIKit keyboard machinery maintains additional state

        that is necessary to manufacture the correct WebEvent corresponding to a UIEvent.

        As a side benefit of this change, with the exception of modifier flag changes, both hardware and software

        key events use the same code path.

        * UIProcess/ios/WKContentViewInteraction.h:

        * UIProcess/ios/WKContentViewInteraction.mm:

        (-[WKContentView _disableAutomaticKeyboardUI]): Implement UIKit SPI to prevent showing the keyboard UI

        when there is no focused element now that we are no longer intercepting key UIEvents. Formerly the

        keyboard UI was disabled as a side effect of not becoming first responder when there was no focused

        element (by returning NO in -_requiresKeyboardWhenFirstResponder).

        (-[WKContentView _requiresKeyboardWhenFirstResponder]): Return YES when there is no focused element.

        (-[WKContentView textInputTraits]): Do not update traits when the keyboard is going to be dismissed

        now that we require a keyboard when first responder even if the focused element is non-editable.

        (-[WKContentView _didHandleKeyEvent:eventWasHandled:]): Skip logic for re-sending UIEvents to UIKit

        as UIKit now processes the event first. This logic was necessary in order to finally allow UIKit

        its chance to interpret the UIEvent, we intercepted, for app key commands.

2019-01-02  Daniel Bates  <dabates@apple.com>

        [iOS] Pressing Tab key doesn't move to next cell with Google Sheets

Source/WebKit/UIProcess/ios/WKContentViewInteraction.h

@@struct WKAutoCorrectionData {

    WebKit::InteractionInformationAtPosition _positionInformation;

    WebKit::FocusedElementInformation _focusedElementInformation;

    RetainPtr<NSObject<WKFormPeripheral>> _inputPeripheral;

259#if !USE(UIKIT_KEYBOARD_ADDITIONS)

259260 RetainPtr<UIEvent> _uiEventBeingResent;

261#endif

    BlockPtr<void(::WebEvent *, BOOL)> _keyWebEventHandler;

    CGPoint _lastInteractionLocation;

Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

#import "WKTextInputListViewController.h"

#import "WKTimePickerViewController.h"

#import "WKUIDelegatePrivate.h"

63 #import "WKWebEvent.h"

#import "WKWebViewConfiguration.h"

#import "WKWebViewConfigurationPrivate.h"

#import "WKWebViewInternal.h"

#import "WKFormColorControl.h"

#endif

#if !USE(UIKIT_KEYBOARD_ADDITIONS)

#import "WKWebEvent.h"

#endif

#if USE(APPLE_INTERNAL_SDK) && __has_include(<WebKitAdditions/WKPlatformFileUploadPanel.mm>)

#import <WebKitAdditions/WKPlatformFileUploadPanel.mm>

#endif

@@- (void)_scrollingNodeScrollingDidEnd

    [_textSelectionAssistant didEndScrollingOverflow];

}

#if USE(UIKIT_KEYBOARD_ADDITIONS)

- (BOOL)_disableAutomaticKeyboardUI

{

    return [self isFirstResponder] && _focusedElementInformation.elementType == WebKit::InputType::None;

}

#endif

- (BOOL)_requiresKeyboardWhenFirstResponder

{

    // FIXME: We should add the logic to handle keyboard visibility during focus redirects.

    switch (_focusedElementInformation.elementType) {

    case WebKit::InputType::None:

#if USE(UIKIT_KEYBOARD_ADDITIONS)

        return YES;

#else

        return NO;

#endif

    case WebKit::InputType::Drawing:

        return NO;

    case WebKit::InputType::Select:

@@- (UITextInputTraits *)textInputTraits

    if (!_traits)

        _traits = adoptNS([[UITextInputTraits alloc] init]);

    // Do not change traits when dismissing the keyboard.

    if (_isBlurringFocusedNode)

        return _traits.get();

    [_traits setSecureTextEntry:_focusedElementInformation.elementType == WebKit::InputType::Password || [_formInputSession forceSecureTextEntry]];

    [_traits setShortcutConversionType:_focusedElementInformation.elementType == WebKit::InputType::Password ? UITextShortcutConversionTypeNo : UITextShortcutConversionTypeDefault];

@@- (BOOL)requiresKeyEvents

    return YES;

}

3971#if !USE(UIKIT_KEYBOARD_ADDITIONS)

- (void)_handleKeyUIEvent:(::UIEvent *)event

{

    bool isHardwareKeyboardEvent = !!event._hidEvent;

@@- (void)handleKeyEvent:(::UIEvent *)event

    
    [self handleKeyWebEvent:webEvent.get()];

}

3996#endif

- (void)handleKeyWebEvent:(::WebEvent *)theEvent

{

@@- (void)_didHandleKeyEvent:(::WebEvent *)event eventWasHandled:(BOOL)eventWasHan

        return;

    }

4024#if !USE(UIKIT_KEYBOARD_ADDITIONS)

    // If we aren't interacting with editable content, we still need to call [super _handleKeyUIEvent:]

    // so that keyboard repeat will work correctly. If we are interacting with editable content,

    // we already did so in _handleKeyUIEvent.

@@- (void)_didHandleKeyEvent:(::WebEvent *)event eventWasHandled:(BOOL)eventWasHan

    _uiEventBeingResent = [(WKWebEvent *)event uiEvent];

    [super _handleKeyUIEvent:_uiEventBeingResent.get()];

    _uiEventBeingResent = nil;

4043#endif

}

- (BOOL)_interpretKeyEvent:(::WebEvent *)event isCharEvent:(BOOL)isCharEvent

Tools/ChangeLog

2019-01-11  Daniel Bates  <dabates@apple.com>

        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element

        https://bugs.webkit.org/show_bug.cgi?id=192824

        <rdar://problem/47100332>

        Reviewed by Wenson Hsieh.

        Fix a bug where the wrong usage code was used for F13 thru F24.

        * WebKitTestRunner/ios/HIDEventGenerator.mm:

        (keyCodeForDOMFunctionKey):

2019-01-15  Chris Dumez  <cdumez@apple.com>

        Regression(PSON) View becomes blank after click a cross-site download link

Tools/WebKitTestRunner/ios/HIDEventGenerator.mm

@@static Optional<uint32_t> keyCodeForDOMFunctionKey(NSString *key)

    }

    for (int i = 13; i <= 24; ++i) {

        if ([key isEqualToString:[NSString stringWithFormat:@"F%d", i]])

837 return kHIDUsage_KeyboardF13 + i - 1;

837 return kHIDUsage_KeyboardF13 + i - 13;

    }

    return WTF::nullopt;

}