⚠ Archived content — this site is no longer maintained.   Current WebKit documentation is at docs.webkit.org.

Changeset 241734 in webkit


Ignore:
Timestamp:
Feb 18, 2019, 1:16:19 PM (8 years ago)
Author:
dbates@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>

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 applyAutocorrection:toString:withCompletionHandler:]): If we are not in an editable
element then we cannot perform the replacement. This logic was necessary now that we always require a
keyboard.
(-[WKContentView requestAutocorrectionContextWithCompletionHandler:]): If we are not in an editable
element then return an autocorrection object that indicates that we could not compute this data. This
logic was necessary now that we always require a keyboard.
(-[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

    r241729 r241734  
     12019-02-18  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-02-18  Eric Carlson  <eric.carlson@apple.com>
    224

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

    r240983 r241734  
    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

    r240983 r241734  
    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

    r240983 r241734  
    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

    r240983 r241734  
    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

    r241729 r241734  
     12019-02-18  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-02-18  Eric Carlson  <eric.carlson@apple.com>
    221

  • trunk/Source/WebCore/PAL/ChangeLog

    r241654 r241734  
     12019-02-18  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-02-17  David Kilzer  <ddkilzer@apple.com>
    214

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

    r240983 r241734  
    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

    r241044 r241734  
    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

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

  • trunk/Source/WebKit/ChangeLog

    r241731 r241734  
     12019-02-18  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 applyAutocorrection:toString:withCompletionHandler:]): If we are not in an editable
     36        element then we cannot perform the replacement. This logic was necessary now that we always require a
     37        keyboard.
     38        (-[WKContentView requestAutocorrectionContextWithCompletionHandler:]): If we are not in an editable
     39        element then return an autocorrection object that indicates that we could not compute this data. This
     40        logic was necessary now that we always require a keyboard.
     41        (-[WKContentView textInputTraits]): Do not update traits when the keyboard is going to be dismissed
     42        now that we require a keyboard when first responder even if the focused element is non-editable.
     43        (-[WKContentView _didHandleKeyEvent:eventWasHandled:]): Skip logic for re-sending UIEvents to UIKit
     44        as UIKit now processes the event first. This logic was necessary in order to finally allow UIKit
     45        its chance to interpret the UIEvent, we intercepted, for app key commands.
     46        (-[WKContentView _elementDidBlur]): Call [self _endEditing] so that we dismiss any open form controls
     47        (e.g. a <select> popover menu). Currently this happens either by -_requiresKeyboardWhenFirstResponder
     48        responding NO when switching to another field or pressing Tab or Shift + Tab key command, which we will
     49        no longer use when building with USE(UIKIT_KEYBOARD_ADDITIONS) once I land <https://bugs.webkit.org/show_bug.cgi?id=193048>.
     50        * UIProcess/ios/forms/WKFormSelectPopover.mm:
     51        (-[WKSelectPopover initWithView:hasGroups:]): Do not assign ourself as the keyboard delegate. Otherwise,
     52        type ahead and tab cycling will not work. Currently type ahead and tab cycling work by using the non-
     53        editable code path via -_handleKeyUIEvent. Now that we no longer differentiate between key events for
     54        editable and non-editable elements we need to ensure that the WKContentView is the keyboard delegate
     55        when the popover is presented.
     56
    1572019-02-18  Jiewen Tan  <jiewen_tan@apple.com>
    258

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

    r241614 r241734  
    262262    WebKit::FocusedElementInformation _focusedElementInformation;
    263263    RetainPtr<NSObject<WKFormPeripheral>> _inputPeripheral;
     264#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    264265    RetainPtr<UIEvent> _uiEventBeingResent;
     266#endif
    265267    BlockPtr<void(::WebEvent *, BOOL)> _keyWebEventHandler;
    266268

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

    r241614 r241734  
    6060#import "WKTimePickerViewController.h"
    6161#import "WKUIDelegatePrivate.h"
    62 #import "WKWebEvent.h"
    6362#import "WKWebViewConfiguration.h"
    6463#import "WKWebViewConfigurationPrivate.h"
    … …  
    123122#if ENABLE(INPUT_TYPE_COLOR)
    124123#import "WKFormColorControl.h"
     124#endif
     125
     126#if !USE(UIKIT_KEYBOARD_ADDITIONS)
     127#import "WKWebEvent.h"
    125128#endif
    126129
    … …  
    14981501}
    14991502
    1500 - (BOOL)_requiresKeyboardWhenFirstResponder
    1501 {
    1502     // FIXME: We should add the logic to handle keyboard visibility during focus redirects.
     1503- (BOOL)shouldShowAutomaticKeyboardUI
     1504{
     1505    // FIXME: Make this function knowledgeable about the HTML attribute inputmode.
    15031506    switch (_focusedElementInformation.elementType) {
    15041507    case WebKit::InputType::None:
    … …  
    15181521    }
    15191522    return NO;
     1523}
     1524
     1525#if USE(UIKIT_KEYBOARD_ADDITIONS)
     1526- (BOOL)_disableAutomaticKeyboardUI
     1527{
     1528    // Always enable automatic keyboard UI if we are not the first responder to avoid
     1529    // interfering with other focused views (e.g. Find-in-page).
     1530    return [self isFirstResponder] && ![self shouldShowAutomaticKeyboardUI];
     1531}
     1532#endif
     1533
     1534- (BOOL)_requiresKeyboardWhenFirstResponder
     1535{
     1536#if USE(UIKIT_KEYBOARD_ADDITIONS)
     1537    return YES;
     1538#else
     1539    // FIXME: We should add the logic to handle keyboard visibility during focus redirects.
     1540    return [self shouldShowAutomaticKeyboardUI];
     1541#endif
    15201542}
    15211543
    … …  
    34583480- (void)applyAutocorrection:(NSString *)correction toString:(NSString *)input withCompletionHandler:(void (^)(UIWKAutocorrectionRects *rectsForCorrection))completionHandler
    34593481{
     3482#if USE(UIKIT_KEYBOARD_ADDITIONS)
     3483    if ([self _disableAutomaticKeyboardUI]) {
     3484        if (completionHandler)
     3485            completionHandler(nil);
     3486        return;
     3487    }
     3488#endif
     3489
    34603490    // FIXME: Remove the synchronous call when <rdar://problem/16207002> is fixed.
    34613491    const bool useSyncRequest = true;
    … …  
    34773507    if (!completionHandler)
    34783508        return;
     3509
     3510#if USE(UIKIT_KEYBOARD_ADDITIONS)
     3511    if ([self _disableAutomaticKeyboardUI]) {
     3512        completionHandler([WKAutocorrectionContext autocorrectionContextWithContext:(WebKit::WebAutocorrectionContext { })]);
     3513        return;
     3514    }
     3515#endif
    34793516
    34803517    // FIXME: Remove the synchronous call when <rdar://problem/16207002> is fixed.
    … …  
    39844021        _traits = adoptNS([[UITextInputTraits alloc] init]);
    39854022
     4023#if USE(UIKIT_KEYBOARD_ADDITIONS)
     4024    // Do not change traits when dismissing the keyboard.
     4025    if (_isBlurringFocusedNode)
     4026        return _traits.get();
     4027#endif
     4028
    39864029    [_traits setSecureTextEntry:_focusedElementInformation.elementType == WebKit::InputType::Password || [_formInputSession forceSecureTextEntry]];
    39874030    [_traits setShortcutConversionType:_focusedElementInformation.elementType == WebKit::InputType::Password ? UITextShortcutConversionTypeNo : UITextShortcutConversionTypeDefault];
    … …  
    41414184}
    41424185
     4186#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    41434187- (void)_handleKeyUIEvent:(::UIEvent *)event
    41444188{
    … …  
    41654209    [self handleKeyWebEvent:webEvent.get()];
    41664210}
     4211#endif
    41674212
    41684213- (void)handleKeyWebEvent:(::WebEvent *)theEvent
    … …  
    41944239    }
    41954240
     4241#if !USE(UIKIT_KEYBOARD_ADDITIONS)
    41964242    // If we aren't interacting with editable content, we still need to call [super _handleKeyUIEvent:]
    41974243    // so that keyboard repeat will work correctly. If we are interacting with editable content,
    … …  
    42124258    [super _handleKeyUIEvent:_uiEventBeingResent.get()];
    42134259    _uiEventBeingResent = nil;
     4260#endif
    42144261}
    42154262
    … …  
    48264873#if HAVE(PENCILKIT)
    48274874    [_drawingCoordinator uninstallInkPicker];
     4875#endif
     4876
     4877#if USE(UIKIT_KEYBOARD_ADDITIONS)
     4878    [self _endEditing];
    48284879#endif
    48294880

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

    r240983 r241734  
    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

    r241733 r241734  
     12019-02-18  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-02-18  Tadeu Zagallo  <tzagallo@apple.com>
    215

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

    r240983 r241734  
    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.