Attachment 369503 Details for Bug 197745 – Patch

[patch] Patch

bug-197745-20190509114223.patch (text/plain), 3.22 KB, created by Daniel Bates on 2019-05-09 11:42:24 PDT

(hide)

Description:

Filename:

MIME Type:

Creator: Daniel Bates

Created: 2019-05-09 11:42:24 PDT

Size: 3.22 KB

patch

obsolete

>Subversion Revision: 244742
>diff --git a/Source/WebKit/ChangeLog b/Source/WebKit/ChangeLog
>index e65217b996dc19162cf6b1c63e6cf74b696c6790..f03e10731efc3db834e841e0dd3e15bd6a5675e1 100644
>--- a/Source/WebKit/ChangeLog
>+++ b/Source/WebKit/ChangeLog
>@@ -1,3 +1,27 @@
>+2019-05-09  Daniel Bates  <dabates@apple.com>
>+
>+        REGRESSION (r241734): 1% slower PLT on iPad
>+        https://bugs.webkit.org/show_bug.cgi?id=197745
>+        <rdar://problem/50457731>
>+
>+        Reviewed by NOBODY (OOPS!).
>+
>+        For now, only create a keyboard when WKContentView becomes first responder if a hardware keyboard
>+        is attached or an editable element is focused to recover the 1% loss when a keyboard is not attached.
>+        We can do better and by that I mean be lazier. We'll do this <https://bugs.webkit.org/show_bug.cgi?id=197746>.
>+
>+        In r241734 we unified the key event handling code paths so we use exactly one for both software and
>+        hardware key events. We took a simple approach of always requesting UIKit to create a keyboard when
>+        the WKContentView becomes first responder. We did this so that we could continue listening for hardware
>+        key events even when a non-editable element is focused and dispatch DOM events. As it turns out, always
>+        creating a keyboard is expensive and caused a ~1% slowdown in page load time on iPad.
>+
>+        * UIProcess/ios/WKContentViewInteraction.mm:
>+        (-[WKContentView _requiresKeyboardWhenFirstResponder]): Only create a keyboard if a hardware keyboard is
>+        attached or an editable element is focused.
>+        (-[WKContentView _hardwareKeyboardAvailabilityChanged]): Reload all input view (this will cause keyboard
>+        creation) if -_requiresKeyboardWhenFirstResponder returns YES.
>+
> 2019-05-08  Daniel Bates  <dabates@apple.com>
> 
>         [iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
>diff --git a/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm b/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
>index 0de6eb310831361f8556828d2e915095c7707ce9..b6c4d8588d728e49aeb6c8c633b3c195980495af 100644
>--- a/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
>+++ b/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
>@@ -1646,12 +1646,14 @@ - (BOOL)_disableAutomaticKeyboardUI
> 
> - (BOOL)_requiresKeyboardWhenFirstResponder
> {
>+    // FIXME: Only create keyboard if [self shouldShowAutomaticKeyboardUI] returns YES or
>+    // on first hardware keydown in a non-editable element. See <https://bugs.webkit.org/show_bug.cgi?id=197746>.
> #if USE(UIKIT_KEYBOARD_ADDITIONS)
>-    return YES;
>-#else
>+    if (GSEventIsHardwareKeyboardAttached())
>+        return YES;
>+#endif
>     // FIXME: We should add the logic to handle keyboard visibility during focus redirects.
>     return [self shouldShowAutomaticKeyboardUI];
>-#endif
> }
> 
> - (BOOL)_requiresKeyboardResetOnReload
>@@ -5182,8 +5184,7 @@ - (void)_elementDidBlur
> 
> - (void)_hardwareKeyboardAvailabilityChanged
> {
>-    if (hasFocusedElement(_focusedElementInformation) && _focusedElementInformation.inputMode == WebCore::InputMode::None)
>-        [self reloadInputViews];
>+    [self reloadInputViews];
> }
> 
> - (void)_didUpdateInputMode:(WebCore::InputMode)mode

Actions: View | Formatted Diff | Diff

Attachments on bug 197745: 369503