Attachment 359345 Details for Bug 192824 – To Land once <rdar://problem/47222115> is fixed

[patch] To Land once <rdar://problem/47222115> is fixed

ToLand_011519.patch (text/plain), 30.76 KB, created by Daniel Bates on 2019-01-16 20:37:08 PST

(hide)

Description:

Filename:

MIME Type:

Creator: Daniel Bates

Created: 2019-01-16 20:37:08 PST

Size: 30.76 KB

patch

obsolete

>From ebd05ae43bff80604633c0a904adc2b5f34463dd Mon Sep 17 00:00:00 2001
>From: Daniel Bates <dabates@apple.com>
>Date: Fri, 11 Jan 2019 16:28:35 -0800
>Subject: [PATCH] [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                         | 22 ++++++++++++
> ...-keys-in-non-editable-element-expected.txt |  4 ++-
> ...-special-keys-in-non-editable-element.html |  8 +++--
> ...-keys-in-non-editable-element-expected.txt | 10 +-----
> ...keypress-keys-in-non-editable-element.html | 10 +++---
> Source/WebCore/ChangeLog                      | 19 ++++++++++
> Source/WebCore/PAL/ChangeLog                  | 12 +++++++
> Source/WebCore/PAL/pal/spi/cocoa/IOKitSPI.h   |  2 ++
> Source/WebCore/platform/ios/KeyEventIOS.mm    | 20 ++++++++++-
> Source/WebCore/platform/ios/WebEvent.mm       | 16 +++++++++
> Source/WebKit/ChangeLog                       | 36 +++++++++++++++++++
> .../UIProcess/ios/WKContentViewInteraction.h  |  2 ++
> .../UIProcess/ios/WKContentViewInteraction.mm | 25 ++++++++++++-
> Tools/ChangeLog                               | 13 +++++++
> .../WebKitTestRunner/ios/HIDEventGenerator.mm |  2 +-
> 15 files changed, 179 insertions(+), 22 deletions(-)
>
>diff --git a/LayoutTests/ChangeLog b/LayoutTests/ChangeLog
>index d44e1b06e89..b68228fb43b 100644
>--- a/LayoutTests/ChangeLog
>+++ b/LayoutTests/ChangeLog
>@@ -1,3 +1,25 @@
>+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
>diff --git a/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt b/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt
>index 0d0c847c9d3..84fc32e69fa 100644
>--- a/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt
>+++ b/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt
>@@ -1,5 +1,7 @@
>-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.
>+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: 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.
> 
>+type: keydown, key: Tab, code: Tab, keyIdentifier: U+0009, keyCode: 9, charCode: 0, keyCode: 9, which: 9
>+type: 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
>diff --git a/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html b/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html
>index cfbb050840d..a824482a91b 100644
>--- a/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html
>+++ b/LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html
>@@ -12,11 +12,12 @@ if (window.testRunner) {
> </script>
> </head>
> <body onkeydown="handleKeyDown(event)" onkeyup="handleKeyUp(event)">
>-<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>.
>+<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>, 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 = [
>+    "\t",
>     "upArrow",
>     "downArrow",
>     "leftArrow",
>@@ -26,7 +27,7 @@ var remainingKeysToPress = [
>     "enter",
>     "escape",
>     "home",
>-    "insert",
>+    // FIXME: Add "insert" once <rdar://problem/47128940> is fixed.
>     "leftAlt",
>     "leftCommand",
>     "leftControl",
>@@ -40,7 +41,8 @@ var remainingKeysToPress = [
>     "rightShift",
> ];
> 
>-for (let i = 1; i <= 24; ++i)
>+// FIXME: Check function keys up to F24 once <rdar://problem/47128940> is fixed.
>+for (let i = 1; i <= 16; ++i)
>     remainingKeysToPress.push("F" + i);
> 
> async function nextKeyPress()
>diff --git a/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element-expected.txt b/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element-expected.txt
>index d0641286510..1a503a8e391 100644
>--- a/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element-expected.txt
>+++ b/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element-expected.txt
>@@ -54,7 +54,7 @@ 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.
>-PASS forwardDelete did dispatch a keypress event.
>+FAIL 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.
>@@ -89,14 +89,6 @@ 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
>diff --git a/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element.html b/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element.html
>index 5fd14ddc793..d4dd00a0025 100644
>--- a/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element.html
>+++ b/LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element.html
>@@ -41,11 +41,8 @@ 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"));
>-
> // Special keys: KeyPress should not be dispatched.
>+tests.push(new TestKeyPressNotDispatchedFor("forwardDelete"));
> tests.push(new TestKeyPressNotDispatchedFor("upArrow"));
> tests.push(new TestKeyPressNotDispatchedFor("downArrow"));
> tests.push(new TestKeyPressNotDispatchedFor("leftArrow"));
>@@ -53,7 +50,7 @@ tests.push(new TestKeyPressNotDispatchedFor("rightArrow"));
> tests.push(new TestKeyPressNotDispatchedFor("clear"));
> tests.push(new TestKeyPressNotDispatchedFor("end"));
> tests.push(new TestKeyPressNotDispatchedFor("home"));
>-tests.push(new TestKeyPressNotDispatchedFor("insert"));
>+// 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"));
>@@ -64,7 +61,8 @@ tests.push(new TestKeyPressNotDispatchedFor("rightAlt"));
> tests.push(new TestKeyPressNotDispatchedFor("rightCommand"));
> tests.push(new TestKeyPressNotDispatchedFor("rightControl"));
> tests.push(new TestKeyPressNotDispatchedFor("rightShift"));
>-for (let i = 1; i <= 24; ++i)
>+// FIXME: Check function keys up to F24 once <rdar://problem/47128940> is fixed.
>+for (let i = 1; i <= 16; ++i)
>     tests.push(new TestKeyPressNotDispatchedFor("F" + i));
> 
> function nextKeyPress()
>diff --git a/Source/WebCore/ChangeLog b/Source/WebCore/ChangeLog
>index b238b0b7ba2..91f007992fa 100644
>--- a/Source/WebCore/ChangeLog
>+++ b/Source/WebCore/ChangeLog
>@@ -1,3 +1,22 @@
>+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
>diff --git a/Source/WebCore/PAL/ChangeLog b/Source/WebCore/PAL/ChangeLog
>index 78773903fb7..241a8d50c58 100644
>--- a/Source/WebCore/PAL/ChangeLog
>+++ b/Source/WebCore/PAL/ChangeLog
>@@ -1,3 +1,15 @@
>+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,
>diff --git a/Source/WebCore/PAL/pal/spi/cocoa/IOKitSPI.h b/Source/WebCore/PAL/pal/spi/cocoa/IOKitSPI.h
>index 207a5d50a39..6a2f1d2431e 100644
>--- a/Source/WebCore/PAL/pal/spi/cocoa/IOKitSPI.h
>+++ b/Source/WebCore/PAL/pal/spi/cocoa/IOKitSPI.h
>@@ -185,6 +185,7 @@ enum {
>     kHIDUsage_KeyboardSlash = 0x38,
>     kHIDUsage_KeyboardCapsLock = 0x39,
>     kHIDUsage_KeyboardF1 = 0x3A,
>+    kHIDUsage_KeyboardF12 = 0x45,
>     kHIDUsage_KeyboardPrintScreen = 0x46,
>     kHIDUsage_KeyboardInsert = 0x49,
>     kHIDUsage_KeyboardHome = 0x4A,
>@@ -198,6 +199,7 @@ enum {
>     kHIDUsage_KeyboardUpArrow = 0x52,
>     kHIDUsage_KeypadNumLock = 0x53,
>     kHIDUsage_KeyboardF13 = 0x68,
>+    kHIDUsage_KeyboardF24 = 0x73,
>     kHIDUsage_KeyboardMenu = 0x76,
>     kHIDUsage_KeyboardLeftControl = 0xE0,
>     kHIDUsage_KeyboardLeftShift = 0xE1,
>diff --git a/Source/WebCore/platform/ios/KeyEventIOS.mm b/Source/WebCore/platform/ios/KeyEventIOS.mm
>index 9bd57e74ac8..f11f6468c07 100644
>--- a/Source/WebCore/platform/ios/KeyEventIOS.mm
>+++ b/Source/WebCore/platform/ios/KeyEventIOS.mm
>@@ -199,13 +199,15 @@ 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;
>-    case 0x1B: return VK_ESCAPE; // WebKit generated code for Escape.
>     case ' ': return VK_SPACE;
> 
>     case '0': case ')': return VK_0;
>@@ -245,6 +247,9 @@ 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;
>@@ -252,6 +257,7 @@ int windowsKeyCodeForCharCode(unichar charCode)
>     case NSRightArrowFunctionKey: return VK_RIGHT;
>     case NSPageUpFunctionKey: return VK_PRIOR;
>     case NSPageDownFunctionKey: return VK_NEXT;
>+#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.
>@@ -273,11 +279,13 @@ int windowsKeyCodeForCharCode(unichar charCode)
> static bool isFunctionKey(UChar charCode)
> {
>     switch (charCode) {
>+#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, ...)
>+#endif
> 
>     // WebKit uses Unicode PUA codes in the OpenStep reserve range for some special keys.
>     case NSUpArrowFunctionKey:
>@@ -287,8 +295,18 @@ 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
>         return true;
>     }
>+#if USE(UIKIT_KEYBOARD_ADDITIONS)
>+    if (charCode >= NSF1FunctionKey && charCode <= NSF24FunctionKey)
>+        return true;
>+#endif
>     return false;
> }
> 
>diff --git a/Source/WebCore/platform/ios/WebEvent.mm b/Source/WebCore/platform/ios/WebEvent.mm
>index 8d88f2bf9ab..aef00167f08 100644
>--- a/Source/WebCore/platform/ios/WebEvent.mm
>+++ b/Source/WebCore/platform/ios/WebEvent.mm
>@@ -153,7 +153,23 @@ 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
>     }
>+#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;
> }
> 
>diff --git a/Source/WebKit/ChangeLog b/Source/WebKit/ChangeLog
>index 448bd84f32d..83e6f4767ec 100644
>--- a/Source/WebKit/ChangeLog
>+++ b/Source/WebKit/ChangeLog
>@@ -1,3 +1,39 @@
>+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
>diff --git a/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h b/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
>index a7ffff78f30..1b268226bc2 100644
>--- a/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
>+++ b/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
>@@ -256,7 +256,9 @@ struct WKAutoCorrectionData {
>     WebKit::InteractionInformationAtPosition _positionInformation;
>     WebKit::FocusedElementInformation _focusedElementInformation;
>     RetainPtr<NSObject<WKFormPeripheral>> _inputPeripheral;
>+#if !USE(UIKIT_KEYBOARD_ADDITIONS)
>     RetainPtr<UIEvent> _uiEventBeingResent;
>+#endif
>     BlockPtr<void(::WebEvent *, BOOL)> _keyWebEventHandler;
> 
>     CGPoint _lastInteractionLocation;
>diff --git a/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm b/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
>index 7a2fe23b0f0..6424a7f3918 100644
>--- a/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
>+++ b/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
>@@ -60,7 +60,6 @@
> #import "WKTextInputListViewController.h"
> #import "WKTimePickerViewController.h"
> #import "WKUIDelegatePrivate.h"
>-#import "WKWebEvent.h"
> #import "WKWebViewConfiguration.h"
> #import "WKWebViewConfigurationPrivate.h"
> #import "WKWebViewInternal.h"
>@@ -125,6 +124,10 @@
> #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
>@@ -1371,11 +1374,23 @@ - (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:
>@@ -3791,6 +3806,10 @@ - (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];
> 
>@@ -3949,6 +3968,7 @@ - (BOOL)requiresKeyEvents
>     return YES;
> }
> 
>+#if !USE(UIKIT_KEYBOARD_ADDITIONS)
> - (void)_handleKeyUIEvent:(::UIEvent *)event
> {
>     bool isHardwareKeyboardEvent = !!event._hidEvent;
>@@ -3973,6 +3993,7 @@ - (void)handleKeyEvent:(::UIEvent *)event
>     
>     [self handleKeyWebEvent:webEvent.get()];
> }
>+#endif
> 
> - (void)handleKeyWebEvent:(::WebEvent *)theEvent
> {
>@@ -4000,6 +4021,7 @@ - (void)_didHandleKeyEvent:(::WebEvent *)event eventWasHandled:(BOOL)eventWasHan
>         return;
>     }
> 
>+#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.
>@@ -4018,6 +4040,7 @@ - (void)_didHandleKeyEvent:(::WebEvent *)event eventWasHandled:(BOOL)eventWasHan
>     _uiEventBeingResent = [(WKWebEvent *)event uiEvent];
>     [super _handleKeyUIEvent:_uiEventBeingResent.get()];
>     _uiEventBeingResent = nil;
>+#endif
> }
> 
> - (BOOL)_interpretKeyEvent:(::WebEvent *)event isCharEvent:(BOOL)isCharEvent
>diff --git a/Tools/ChangeLog b/Tools/ChangeLog
>index ff14b37efd6..bb23bd34cd9 100644
>--- a/Tools/ChangeLog
>+++ b/Tools/ChangeLog
>@@ -1,3 +1,16 @@
>+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
>diff --git a/Tools/WebKitTestRunner/ios/HIDEventGenerator.mm b/Tools/WebKitTestRunner/ios/HIDEventGenerator.mm
>index 2816c598a10..c3996a84587 100644
>--- a/Tools/WebKitTestRunner/ios/HIDEventGenerator.mm
>+++ b/Tools/WebKitTestRunner/ios/HIDEventGenerator.mm
>@@ -834,7 +834,7 @@ static Optional<uint32_t> keyCodeForDOMFunctionKey(NSString *key)
>     }
>     for (int i = 13; i <= 24; ++i) {
>         if ([key isEqualToString:[NSString stringWithFormat:@"F%d", i]])
>-            return kHIDUsage_KeyboardF13 + i - 1;
>+            return kHIDUsage_KeyboardF13 + i - 13;
>     }
>     return WTF::nullopt;
> }
>-- 
>2.20.0 (Apple Git-115)
>

Actions: View | Formatted Diff | Diff

Attachments on bug 192824: 358651 | 358654 | 358962 | 359345 | 359978 | 360632 | 361561 | 361590 | 361632 | 361634 | 361638 | 362317 | 362319