tree 760a44060ba66f12372133c14bb9052657203d8e
parent fe3f8a9f58c921838bd3a920db5f85be838171cd
author wenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1579041455 +0000
committer wenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc> 1579041455 +0000

[iOS] Keyboard input is severely delayed after switching away from unresponsive tab
https://bugs.webkit.org/show_bug.cgi?id=206242
<rdar://problem/57132891>

Reviewed by Tim Horton.

Source/WebKit:

UIKit delivers key events to WKWebView using asynchronous SPI (-handleKeyWebEvent:withCompletionHandler:). The
completion handler is invoked when the web page has processed the event, and determines whether to proceed with
default behavior via the `BOOL handled` argument. Using UIKeyboardImpl's UIKeyboardTaskQueue, UIKit appends
subsequent key events to a queue, to be processed by the current first responder after the current key event
has been handled.

In the scenario where the web page is completely unresponsive, this means key events that come after an event
that has been dispatched to the unresponsive page will be stuck in the task queue; this manifests in behaviors
similar to the one in this bug:

- Using a hardware keyboard, press any key in an unresponsive page in Safari.
- Press CMD+T (to create a new tab and focus the unified field) or CMT+L (to just focus the unified field).
- Try to type in the unified field.

The result is that no characters are inserted in the unified field, because the hardware key events are stuck in
UIKeyboardTaskQueue waiting for the unresponsive page to finish handling the current key event. To fix this, we
introduce a mechanism for invoking the key event handler on WKContentView before the web page has actually
finished processing the event, but only in the case where the web view has resigned first responder (and
therefore won't receive subsequent key events anyways).

Tests:  KeyboardInputTests.ResigningFirstResponderCancelsKeyEvents
        KeyboardInputTests.WaitForKeyEventHandlerInFirstResponder

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::hasQueuedKeyEvent const):
(WebKit::WebPageProxy::firstQueuedKeyEvent const):
* UIProcess/WebPageProxy.h:
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView resignFirstResponderForWebView]):

After the content view has resigned first responder with a pending key event handler (and if it did not
immediately become first responder again in the same runloop), then invoke the key event handler early, passing
in `YES` for `handled` to prevent any default actions such as text insertion from being dispatched to the view.

Tools:

Add a couple of new API tests: (1) verify that the key event completion handler can still be invoked in an
unresponsive web view after resigning first responder, and (2) verify that we'll try to wait for the current
key event to be processed in a web view, if it remains the first responder.

* TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@254538 268f45cc-cd09-0410-ab3c-d52691b4dbfc