Title: [245226] branches/safari-608.1.24-branch/Source/WebKit
- Revision
- 245226
- Author
- bshaf...@apple.com
- Date
- 2019-05-12 23:51:05 -0700 (Sun, 12 May 2019)
Log 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
Modified Paths
Diff
Modified: branches/safari-608.1.24-branch/Source/WebKit/ChangeLog (245225 => 245226)
--- branches/safari-608.1.24-branch/Source/WebKit/ChangeLog 2019-05-13 06:51:02 UTC (rev 245225)
+++ branches/safari-608.1.24-branch/Source/WebKit/ChangeLog 2019-05-13 06:51:05 UTC (rev 245226)
@@ -1,5 +1,57 @@
2019-05-12 Babak Shafiei <bshaf...@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 <daba...@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 <bshaf...@apple.com>
+
Cherry-pick r245144. rdar://problem/47902054
[iOS] Unable to commit search on MSN.com, qq.com, or sina.com.cn using enter key (hardware or software keyboard)
Modified: branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (245225 => 245226)
--- branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-05-13 06:51:02 UTC (rev 245225)
+++ branches/safari-608.1.24-branch/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2019-05-13 06:51:05 UTC (rev 245226)
@@ -1664,12 +1664,14 @@
- (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
@@ -5218,8 +5220,7 @@
- (void)_hardwareKeyboardAvailabilityChanged
{
- if (hasFocusedElement(_focusedElementInformation) && _focusedElementInformation.inputMode == WebCore::InputMode::None)
- [self reloadInputViews];
+ [self reloadInputViews];
}
- (void)_didUpdateInputMode:(WebCore::InputMode)mode
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
