Changeset 245226 in webkit

Timestamp:

May 12, 2019, 11:51:05 PM (7 years ago)

Author:

bshafiei@apple.com

Message:

Cherry-pick r245148. rdar://problem/50457731

REGRESSION (r241734): 1% slower PLT on iPad
​https://bugs.webkit.org/show_bug.cgi?id=197745
<rdar://problem/50457731>

Reviewed by Per Arne Vollan.

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.

git-svn-id: ​https://svn.webkit.org/repository/webkit/trunk@245148 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Location:

branches/safari-608.1.24-branch/Source/WebKit

Files:

• ChangeLog (modified) (1 diff)
• UIProcess/ios/WKContentViewInteraction.mm (modified) (2 diffs)

branches/safari-608.1.24-branch/Source/WebKit/ChangeLog

@@ +1 @@
+2019-05-12  Babak Shafiei  <bshafiei@apple.com>
+
+        Cherry-pick r245148. rdar://problem/50457731
+
+    REGRESSION (r241734): 1% slower PLT on iPad
+    https://bugs.webkit.org/show_bug.cgi?id=197745
+    <rdar://problem/50457731>
+    
+    Reviewed by Per Arne Vollan.
+    
+    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.
+    
+    git-svn-id: https://svn.webkit.org/repository/webkit/trunk@245148 268f45cc-cd09-0410-ab3c-d52691b4dbfc
+
+    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 Per Arne Vollan.
+
+            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-12  Babak Shafiei  <bshafiei@apple.com>
 

branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

@@ -1665 +1665 @@
 - (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
 }
 
@@ -5219 +5221 @@
 - (void)_hardwareKeyboardAvailabilityChanged
 {
-    if (hasFocusedElement(_focusedElementInformation) && _focusedElementInformation.inputMode == WebCore::InputMode::None)
-        [self reloadInputViews];
+    [self reloadInputViews];
 }