Changeset 240742 in webkit


Ignore:
Timestamp:
Jan 30, 2019 4:54:04 PM (5 years ago)
Author:
commit-queue@webkit.org
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>

Patch by Daniel Bates <​dabates@apple.com> on 2019-01-30
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 shouldShowAutomaticKeyboardUI]): Extracted code from _requiresKeyboardWhenFirstResponder
(-[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]): Always return YES when building with USE(UIKIT_KEYBOARD_ADDITIONS)
so that we always accept key events. Instead of selectively replying to create a keyboard as a means of
hiding the automatic keyboard UI we now implement _disableAutomaticKeyboardUI to selectively hide the
automatic keyboard UI.
(-[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.
(-[WKContentView _elementDidBlur]): Call [self _endEditing] so that we dismiss any open form controls
(e.g. a <select> popover menu). Currently this happens either by -_requiresKeyboardWhenFirstResponder
responding NO when switching to another field or pressing Tab or Shift + Tab key command, which we will
no longer use when building with USE(UIKIT_KEYBOARD_ADDITIONS) once I land <​https://bugs.webkit.org/show_bug.cgi?id=193048>.

  • UIProcess/ios/forms/WKFormSelectPopover.mm:

(-[WKSelectPopover initWithView:hasGroups:]): Do not assign ourself as the keyboard delegate. Otherwise,
type ahead and tab cycling will not work. Currently type ahead and tab cycling work by using the non-
editable code path via -_handleKeyUIEvent. Now that we no longer differentiate between key events for
editable and non-editable elements we need to ensure that the WKContentView is the keyboard delegate
when the popover is presented.

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:
Location:
trunk
Files:
16 edited

Legend:

Unmodified
Added
Removed

  • trunk/LayoutTests/ChangeLog

    r240721 r240742  
     12019-01-30  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element
     4        https://bugs.webkit.org/show_bug.cgi?id=192824
     5        <rdar://problem/47100332>
     6
     7        Reviewed by Wenson Hsieh.
     8
     9        Update tests and expected results. As it turns out fixing the bug in WebKitTestRunner/ios/HIDEventGenerator.mm
     10        so that we now dispatch key events for F17 thru F24 exposed a bug in UIKit. See <rdar://problem/47128940>.
     11        This same bug is also responsible for a lack of key events when the Insert key is pressed.
     12
     13        Added sub-test for Tab key to keypress-keys-in-non-editable-element.html. Changed expected result in test
     14        keypress-keys-in-non-editable-element.html for the forward delete key to expect failure. We expect that pressing
     15        the forward delete key will not dispatch a keypress to match the behavior on Mac. This will be addressed by a
     16        UIKit fix.
     17
     18        * fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt:
     19        * fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html:
     20        * fast/events/ios/keypress-keys-in-non-editable-element-expected.txt:
     21        * fast/events/ios/keypress-keys-in-non-editable-element.html:
     22
    1232019-01-30  Dean Jackson  <dino@apple.com>
    224

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

    r237738 r240742  
    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
    35type: keydown, key: ArrowUp, code: ArrowUp, keyIdentifier: Up, keyCode: 38, charCode: 0, keyCode: 38, which: 38
    46type: keyup, key: ArrowUp, code: ArrowUp, keyIdentifier: Up, keyCode: 38, charCode: 0, keyCode: 38, which: 38

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

    r236271 r240742  
    1313</head>
    1414<body onkeydown="handleKeyDown(event)" onkeyup="handleKeyUp(event)">
    15 <p>This tests that DOM keydown and keyup events are dispatched to a non-editable &lt;body&gt; 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 &lt;body&gt; 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><!-- FIXME: Add <kbd>Insert</kbd> once <rdar://problem/47128940> is fixed. -->, 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><!-- FIXME: Add <kbd>F17</kbd>, <kbd>F18</kbd>, <kbd>F19</kbd>, <kbd>F20</kbd>, <kbd>F21</kbd>, <kbd>F22</kbd>, <kbd>F23</kbd>, <kbd>F24</kbd> once <rdar://problem/47128940> is fixed.-->.
    1616</p>
    1717<pre id="console"></pre>
    1818<script>
    1919var remainingKeysToPress = [
     20    "\t",
    2021    "upArrow",
    2122    "downArrow",
    … …  
    2728    "escape",
    2829    "home",
    29     "insert",
     30    // FIXME: Add "insert" once <rdar://problem/47128940> is fixed.
    3031    "leftAlt",
    3132    "leftCommand",
    … …  
    4142];
    4243
    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)
    4446    remainingKeysToPress.push("F" + i);
    4547

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

    r236678 r240742  
    5555PASS escape did dispatch a keypress event.
    5656PASS return did dispatch a keypress event.
    57 PASS forwardDelete did dispatch a keypress event.
     57FAIL forwardDelete should not have dispatched a keypress event. It did dispatch one.
    5858PASS upArrow did not dispatch a keypress event.
    5959PASS downArrow did not dispatch a keypress event.
    … …  
    9090PASS F15 did not dispatch a keypress event.
    9191PASS F16 did not dispatch a keypress event.
    92 PASS F17 did not dispatch a keypress event.
    93 PASS F18 did not dispatch a keypress event.
    94 PASS F19 did not dispatch a keypress event.
    95 PASS F20 did not dispatch a keypress event.
    96 PASS F21 did not dispatch a keypress event.
    97 PASS F22 did not dispatch a keypress event.
    98 PASS F23 did not dispatch a keypress event.
    99 PASS F24 did not dispatch a keypress event.
    10092PASS successfullyParsed is true
    10193

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

    r236678 r240742  
    4242tests.push(new TestKeyPressDispatchedFor("return"));
    4343
    44 // The forward delete key is mapped to the delete key on iOS and dispatches a keypress event.
    45 // On Mac it is treated as its own key and does not dispatch a keypress event.
    46 tests.push(new TestKeyPressDispatchedFor("forwardDelete"));
    47 
    4844// Special keys: KeyPress should not be dispatched.
     45tests.push(new TestKeyPressNotDispatchedFor("forwardDelete"));
    4946tests.push(new TestKeyPressNotDispatchedFor("upArrow"));
    5047tests.push(new TestKeyPressNotDispatchedFor("downArrow"));
    … …  
    5451tests.push(new TestKeyPressNotDispatchedFor("end"));
    5552tests.push(new TestKeyPressNotDispatchedFor("home"));
    56 tests.push(new TestKeyPressNotDispatchedFor("insert"));
     53// FIXME: Test that keypress is not dispatched for "insert" once <rdar://problem/47128940> is fixed.
    5754tests.push(new TestKeyPressNotDispatchedFor("leftAlt"));
    5855tests.push(new TestKeyPressNotDispatchedFor("leftCommand"));
    … …  
    6562tests.push(new TestKeyPressNotDispatchedFor("rightControl"));
    6663tests.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)
    6866    tests.push(new TestKeyPressNotDispatchedFor("F" + i));
    6967

  • trunk/Source/WebCore/ChangeLog

    r240738 r240742  
     12019-01-30  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element
     4        https://bugs.webkit.org/show_bug.cgi?id=192824
     5        <rdar://problem/47100332>
     6
     7        Reviewed by Wenson Hsieh.
     8
     9        When building with USE(UIKIT_KEYBOARD_ADDITIONS) enabled, normalize input strings for some more key codes
     10        now that hardware key events to non-editable elements use the same code path as for editable elements.
     11
     12        * platform/ios/KeyEventIOS.mm:
     13        (WebCore::windowsKeyCodeForCharCode): Demarcate mappings that are only needed when building with
     14        !USE(UIKIT_KEYBOARD_ADDITIONS) in the hope that one day we can remove this code.
     15        (WebCore::isFunctionKey): Ditto.
     16        * platform/ios/WebEvent.mm:
     17        (normalizedStringWithAppKitCompatibilityMapping): Normalize some more input strings when building with
     18        USE(UIKIT_KEYBOARD_ADDITIONS) enabled.
     19
    1202019-01-30  Jer Noble  <jer.noble@apple.com>
    221

  • trunk/Source/WebCore/PAL/ChangeLog

    r240633 r240742  
     12019-01-30  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element
     4        https://bugs.webkit.org/show_bug.cgi?id=192824
     5        <rdar://problem/47100332>
     6
     7        Reviewed by Wenson Hsieh.
     8
     9        Expose more enumerators.
     10
     11        * pal/spi/cocoa/IOKitSPI.h:
     12
    1132019-01-28  Andy Estes  <aestes@apple.com>
    214

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

    r239277 r240742  
    186186    kHIDUsage_KeyboardCapsLock = 0x39,
    187187    kHIDUsage_KeyboardF1 = 0x3A,
     188    kHIDUsage_KeyboardF12 = 0x45,
    188189    kHIDUsage_KeyboardPrintScreen = 0x46,
    189190    kHIDUsage_KeyboardInsert = 0x49,
    … …  
    199200    kHIDUsage_KeypadNumLock = 0x53,
    200201    kHIDUsage_KeyboardF13 = 0x68,
     202    kHIDUsage_KeyboardF24 = 0x73,
    201203    kHIDUsage_KeyboardMenu = 0x76,
    202204    kHIDUsage_KeyboardLeftControl = 0xE0,

  • trunk/Source/WebCore/platform/ios/KeyEventIOS.mm

    r240641 r240742  
    198198}
    199199
     200// This function is only used to map software keyboard events because they lack a key code.
     201// When !USE(UIKIT_KEYBOARD_ADDITIONS), this function is also used to map hardware keyboard
     202// keyup events because they lack a key code.
    200203int windowsKeyCodeForCharCode(unichar charCode)
    201204{
    … …  
    204207    case 9: return VK_TAB;
    205208    case 0xD: case 3: return VK_RETURN;
    206     case 0x1B: return VK_ESCAPE; // WebKit generated code for Escape.
    207209    case ' ': return VK_SPACE;
    208210
    … …  
    244246    case 'z': case 'Z': return VK_Z;
    245247
     248#if !USE(UIKIT_KEYBOARD_ADDITIONS)
     249    case 0x1B: return VK_ESCAPE; // WebKit generated code for Escape.
     250
    246251    // WebKit uses Unicode PUA codes in the OpenStep reserve range for some special keys.
    247252    case NSUpArrowFunctionKey: return VK_UP;
    … …  
    251256    case NSPageUpFunctionKey: return VK_PRIOR;
    252257    case NSPageDownFunctionKey: return VK_NEXT;
     258#endif
    253259
    254260    // This is for U.S. keyboard mapping, and doesn't necessarily make sense for different keyboard layouts.
    … …  
    272278{
    273279    switch (charCode) {
     280#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    274281    case 1: // Home
    275282    case 4: // End
    … …  
    277284    case 0x7F: // Forward Delete
    278285    case 0x10: // Function key (e.g. F1, F2, ...)
     286#endif
    279287
    280288    // WebKit uses Unicode PUA codes in the OpenStep reserve range for some special keys.
    … …  
    286294    case NSPageDownFunctionKey:
    287295    case NSClearLineFunctionKey: // Num Lock / Clear
     296#if USE(UIKIT_KEYBOARD_ADDITIONS)
     297    case NSDeleteFunctionKey: // Forward delete
     298    case NSEndFunctionKey:
     299    case NSInsertFunctionKey:
     300    case NSHomeFunctionKey:
     301#endif
    288302        return true;
    289303    }
     304#if USE(UIKIT_KEYBOARD_ADDITIONS)
     305    if (charCode >= NSF1FunctionKey && charCode <= NSF24FunctionKey)
     306        return true;
     307#endif
    290308    return false;
    291309}

  • trunk/Source/WebCore/platform/ios/WebEvent.mm

    r240168 r240742  
    149149    case kHIDUsage_KeypadNumLock: // Num Lock / Clear
    150150        return makeNSStringWithCharacter(NSClearLineFunctionKey);
    151     }
     151#if USE(UIKIT_KEYBOARD_ADDITIONS)
     152    case kHIDUsage_KeyboardDeleteForward:
     153        return makeNSStringWithCharacter(NSDeleteFunctionKey);
     154    case kHIDUsage_KeyboardEnd:
     155        return makeNSStringWithCharacter(NSEndFunctionKey);
     156    case kHIDUsage_KeyboardInsert:
     157        return makeNSStringWithCharacter(NSInsertFunctionKey);
     158    case kHIDUsage_KeyboardHome:
     159        return makeNSStringWithCharacter(NSHomeFunctionKey);
     160#endif
     161    }
     162#if USE(UIKIT_KEYBOARD_ADDITIONS)
     163    if (keyCode >= kHIDUsage_KeyboardF1 && keyCode <= kHIDUsage_KeyboardF12)
     164        return makeNSStringWithCharacter(NSF1FunctionKey + (keyCode - kHIDUsage_KeyboardF1));
     165    if (keyCode >= kHIDUsage_KeyboardF13 && keyCode <= kHIDUsage_KeyboardF24)
     166        return makeNSStringWithCharacter(NSF13FunctionKey + (keyCode - kHIDUsage_KeyboardF13));
     167#endif
    152168    return characters;
    153169}

  • trunk/Source/WebKit/ChangeLog

    r240733 r240742  
     12019-01-30  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element
     4        https://bugs.webkit.org/show_bug.cgi?id=192824
     5        <rdar://problem/47100332>
     6
     7        Reviewed by Wenson Hsieh.
     8
     9        Use the same code path for key events to editable elements and non-editable elements.
     10
     11        Currently we have different code paths for hardware key events depending on whether the active element
     12        is editable or non-editable. Historically to support dispatching DOM keyboard events for hardware key
     13        presses this differentiation was a necessary workaround for UIKit's event processing precedence of
     14        interpreting key events for system text editing commands and app commands before dispatching unhandled
     15        key events to WebKit. This workaround intercepted raw key UIEvents and manually reconstructed a
     16        WebEvent from it. However there is not enough information in an UIEvent to reconstruct a WebEvent that
     17        is identical to the WebEvent that UIKit would have dispatched. In particular, keyup UIEvents always have
     18        empty modified and unmodified input strings. The UIKit keyboard machinery maintains additional state
     19        that is necessary to manufacture the correct WebEvent corresponding to a UIEvent.
     20
     21        As a side benefit of this change, with the exception of modifier flag changes, both hardware and software
     22        key events use the same code path.
     23
     24        * UIProcess/ios/WKContentViewInteraction.h:
     25        * UIProcess/ios/WKContentViewInteraction.mm:
     26        (-[WKContentView shouldShowAutomaticKeyboardUI]): Extracted code from _requiresKeyboardWhenFirstResponder
     27        (-[WKContentView _disableAutomaticKeyboardUI]): Implement UIKit SPI to prevent showing the keyboard UI
     28        when there is no focused element now that we are no longer intercepting key UIEvents. Formerly the
     29        keyboard UI was disabled as a side effect of not becoming first responder when there was no focused
     30        element (by returning NO in -_requiresKeyboardWhenFirstResponder).
     31        (-[WKContentView _requiresKeyboardWhenFirstResponder]): Always return YES when building with USE(UIKIT_KEYBOARD_ADDITIONS)
     32        so that we always accept key events. Instead of selectively replying to create a keyboard as a means of
     33        hiding the automatic keyboard UI we now implement _disableAutomaticKeyboardUI to selectively hide the
     34        automatic keyboard UI.
     35        (-[WKContentView textInputTraits]): Do not update traits when the keyboard is going to be dismissed
     36        now that we require a keyboard when first responder even if the focused element is non-editable.
     37        (-[WKContentView _didHandleKeyEvent:eventWasHandled:]): Skip logic for re-sending UIEvents to UIKit
     38        as UIKit now processes the event first. This logic was necessary in order to finally allow UIKit
     39        its chance to interpret the UIEvent, we intercepted, for app key commands.
     40        (-[WKContentView _elementDidBlur]): Call [self _endEditing] so that we dismiss any open form controls
     41        (e.g. a <select> popover menu). Currently this happens either by -_requiresKeyboardWhenFirstResponder
     42        responding NO when switching to another field or pressing Tab or Shift + Tab key command, which we will
     43        no longer use when building with USE(UIKIT_KEYBOARD_ADDITIONS) once I land <https://bugs.webkit.org/show_bug.cgi?id=193048>.
     44        * UIProcess/ios/forms/WKFormSelectPopover.mm:
     45        (-[WKSelectPopover initWithView:hasGroups:]): Do not assign ourself as the keyboard delegate. Otherwise,
     46        type ahead and tab cycling will not work. Currently type ahead and tab cycling work by using the non-
     47        editable code path via -_handleKeyUIEvent. Now that we no longer differentiate between key events for
     48        editable and non-editable elements we need to ensure that the WKContentView is the keyboard delegate
     49        when the popover is presented.
     50
    1512019-01-30  Per Arne Vollan  <pvollan@apple.com>
    252

  • trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h

    r240579 r240742  
    261261    WebKit::FocusedElementInformation _focusedElementInformation;
    262262    RetainPtr<NSObject<WKFormPeripheral>> _inputPeripheral;
     263#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    263264    RetainPtr<UIEvent> _uiEventBeingResent;
     265#endif
    264266    BlockPtr<void(::WebEvent *, BOOL)> _keyWebEventHandler;
    265267

  • trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

    r240687 r240742  
    6060#import "WKTimePickerViewController.h"
    6161#import "WKUIDelegatePrivate.h"
    62 #import "WKWebEvent.h"
    6362#import "WKWebViewConfiguration.h"
    6463#import "WKWebViewConfigurationPrivate.h"
    … …  
    122121#if ENABLE(INPUT_TYPE_COLOR)
    123122#import "WKFormColorControl.h"
     123#endif
     124
     125#if !USE(UIKIT_KEYBOARD_ADDITIONS)
     126#import "WKWebEvent.h"
    124127#endif
    125128
    … …  
    14561459}
    14571460
    1458 - (BOOL)_requiresKeyboardWhenFirstResponder
    1459 {
    1460     // FIXME: We should add the logic to handle keyboard visibility during focus redirects.
     1461- (BOOL)shouldShowAutomaticKeyboardUI
     1462{
     1463    // FIXME: Make this function knowledgeable about the HTML attribute inputmode.
    14611464    switch (_focusedElementInformation.elementType) {
    14621465    case WebKit::InputType::None:
    … …  
    14761479    }
    14771480    return NO;
     1481}
     1482
     1483#if USE(UIKIT_KEYBOARD_ADDITIONS)
     1484- (BOOL)_disableAutomaticKeyboardUI
     1485{
     1486    // Always enable automatic keyboard UI if we are not the first responder to avoid
     1487    // interfering with other focused views (e.g. Find-in-page).
     1488    return [self isFirstResponder] && ![self shouldShowAutomaticKeyboardUI];
     1489}
     1490#endif
     1491
     1492- (BOOL)_requiresKeyboardWhenFirstResponder
     1493{
     1494#if USE(UIKIT_KEYBOARD_ADDITIONS)
     1495    return YES;
     1496#else
     1497    // FIXME: We should add the logic to handle keyboard visibility during focus redirects.
     1498    return [self shouldShowAutomaticKeyboardUI];
     1499#endif
    14781500}
    14791501
    … …  
    38753897        _traits = adoptNS([[UITextInputTraits alloc] init]);
    38763898
     3899#if USE(UIKIT_KEYBOARD_ADDITIONS)
     3900    // Do not change traits when dismissing the keyboard.
     3901    if (_isBlurringFocusedNode)
     3902        return _traits.get();
     3903#endif
     3904
    38773905    [_traits setSecureTextEntry:_focusedElementInformation.elementType == WebKit::InputType::Password || [_formInputSession forceSecureTextEntry]];
    38783906    [_traits setShortcutConversionType:_focusedElementInformation.elementType == WebKit::InputType::Password ? UITextShortcutConversionTypeNo : UITextShortcutConversionTypeDefault];
    … …  
    40324060}
    40334061
     4062#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    40344063- (void)_handleKeyUIEvent:(::UIEvent *)event
    40354064{
    … …  
    40564085    [self handleKeyWebEvent:webEvent.get()];
    40574086}
     4087#endif
    40584088
    40594089- (void)handleKeyWebEvent:(::WebEvent *)theEvent
    … …  
    40834113    }
    40844114
     4115#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    40854116    // If we aren't interacting with editable content, we still need to call [super _handleKeyUIEvent:]
    40864117    // so that keyboard repeat will work correctly. If we are interacting with editable content,
    … …  
    41014132    [super _handleKeyUIEvent:_uiEventBeingResent.get()];
    41024133    _uiEventBeingResent = nil;
     4134#endif
    41034135}
    41044136
    … …  
    47054737#if HAVE(PENCILKIT)
    47064738    [_drawingCoordinator uninstallInkPicker];
     4739#endif
     4740
     4741#if USE(UIKIT_KEYBOARD_ADDITIONS)
     4742    [self _endEditing];
    47074743#endif
    47084744

  • trunk/Source/WebKit/UIProcess/ios/forms/WKFormSelectPopover.mm

    r239454 r240742  
    7979@class WKSelectPopover;
    8080
     81#if USE(UIKIT_KEYBOARD_ADDITIONS)
     82@interface WKSelectTableViewController : UITableViewController
     83#else
    8184@interface WKSelectTableViewController : UITableViewController <UIKeyInput>
     85#endif
    8286{
    8387    NSUInteger _singleSelectionIndex;
    … …  
    360364}
    361365
     366#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    362367#pragma mark UIKeyInput delegate methods
    363368
    … …  
    374379{
    375380}
     381
     382#endif
    376383
    377384@end
    … …  
    411418
    412419    [navController release];
    413    
     420
     421#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    414422    [[UIKeyboardImpl sharedInstance] setDelegate:_tableViewController.get()];
     423#endif
    415424   
    416425    return self;

  • trunk/Tools/ChangeLog

    r240725 r240742  
     12019-01-30  Daniel Bates  <dabates@apple.com>
     2
     3        [iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content-editable element
     4        https://bugs.webkit.org/show_bug.cgi?id=192824
     5        <rdar://problem/47100332>
     6
     7        Reviewed by Wenson Hsieh.
     8
     9        Fix a bug where the wrong usage code was used for F13 thru F24.
     10
     11        * WebKitTestRunner/ios/HIDEventGenerator.mm:
     12        (keyCodeForDOMFunctionKey):
     13
    1142019-01-30  Chris Dumez  <cdumez@apple.com>
    215

  • trunk/Tools/WebKitTestRunner/ios/HIDEventGenerator.mm

    r240512 r240742  
    835835    for (int i = 13; i <= 24; ++i) {
    836836        if ([key isEqualToString:[NSString stringWithFormat:@"F%d", i]])
    837             return kHIDUsage_KeyboardF13 + i - 1;
     837            return kHIDUsage_KeyboardF13 + i - 13;
    838838    }
    839839    return WTF::nullopt;
Note: See TracChangeset for help on using the changeset viewer.