[iOS] Keyups for non-modifier keys identified as "Dead" when not focused in a content...
authorcommit-queue@webkit.org <commit-queue@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 31 Jan 2019 00:54:04 +0000 (00:54 +0000)
committercommit-queue@webkit.org <commit-queue@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 31 Jan 2019 00:54:04 +0000 (00:54 +0000)
commit555154e13fff924dae0b30b4a6c193f455a9b1b4
treeb35f698d9c6253e14e6af4fd37a17653f494a0d6
parent4656d9110973553f39c831f1830b59ca84dd7290
[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:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@240742 268f45cc-cd09-0410-ab3c-d52691b4dbfc
16 files changed:
LayoutTests/ChangeLog
LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element-expected.txt
LayoutTests/fast/events/ios/keydown-keyup-special-keys-in-non-editable-element.html
LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element-expected.txt
LayoutTests/fast/events/ios/keypress-keys-in-non-editable-element.html
Source/WebCore/ChangeLog
Source/WebCore/PAL/ChangeLog
Source/WebCore/PAL/pal/spi/cocoa/IOKitSPI.h
Source/WebCore/platform/ios/KeyEventIOS.mm
Source/WebCore/platform/ios/WebEvent.mm
Source/WebKit/ChangeLog
Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Source/WebKit/UIProcess/ios/forms/WKFormSelectPopover.mm
Tools/ChangeLog
Tools/WebKitTestRunner/ios/HIDEventGenerator.mm