Title: [265238] trunk
- Revision
- 265238
- Author
- wenson_hs...@apple.com
- Date
- 2020-08-03 19:33:28 -0700 (Mon, 03 Aug 2020)
Log Message
Allow -accessoryDone to blur the focused element on iPad when AutoFilling strong passwords
https://bugs.webkit.org/show_bug.cgi?id=215105
<rdar://problem/65143984>
Reviewed by Tim Horton.
Source/WebKit:
`-accessoryDone` is now used to dismiss the strong password AutoFill keyboard after choosing a password on iOS,
due to how it hides the keyboard without causing the content view to resign first responder; being stuck in a
state where the content view is not first responder causes several issues when choosing strong passwords on iOS,
such as keyboard shortcuts no longer working.
On iPad, to ensure that `-accessoryDone` actually dismisses the keyboard, we need to additionally teach
`-endEditingAndUpdateFocusAppearanceWithReason:` (when given `EndEditingReasonAccessoryDone`) to allow the
focused element to blur when dismissing the strong password input view.
Test: KeyboardInputTests.TestWebViewAccessoryDoneDuringStrongPasswordAssistance
* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView endEditingAndUpdateFocusAppearanceWithReason:]):
Refactor this logic into a local helper lambda with early returns, instead of using a single if statement.
Tools:
Add an API test that exercises the behavior change when run on iPad simulator.
* TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
* TestWebKitAPI/ios/UIKitSPI.h:
Modified Paths
Diff
Modified: trunk/Source/WebKit/ChangeLog (265237 => 265238)
--- trunk/Source/WebKit/ChangeLog 2020-08-04 01:51:14 UTC (rev 265237)
+++ trunk/Source/WebKit/ChangeLog 2020-08-04 02:33:28 UTC (rev 265238)
@@ -1,3 +1,27 @@
+2020-08-03 Wenson Hsieh <wenson_hs...@apple.com>
+
+ Allow -accessoryDone to blur the focused element on iPad when AutoFilling strong passwords
+ https://bugs.webkit.org/show_bug.cgi?id=215105
+ <rdar://problem/65143984>
+
+ Reviewed by Tim Horton.
+
+ `-accessoryDone` is now used to dismiss the strong password AutoFill keyboard after choosing a password on iOS,
+ due to how it hides the keyboard without causing the content view to resign first responder; being stuck in a
+ state where the content view is not first responder causes several issues when choosing strong passwords on iOS,
+ such as keyboard shortcuts no longer working.
+
+ On iPad, to ensure that `-accessoryDone` actually dismisses the keyboard, we need to additionally teach
+ `-endEditingAndUpdateFocusAppearanceWithReason:` (when given `EndEditingReasonAccessoryDone`) to allow the
+ focused element to blur when dismissing the strong password input view.
+
+ Test: KeyboardInputTests.TestWebViewAccessoryDoneDuringStrongPasswordAssistance
+
+ * UIProcess/ios/WKContentViewInteraction.mm:
+ (-[WKContentView endEditingAndUpdateFocusAppearanceWithReason:]):
+
+ Refactor this logic into a local helper lambda with early returns, instead of using a single if statement.
+
2020-08-03 Youenn Fablet <you...@apple.com>
Move user gesture propagation over promise behind a feature flag
Modified: trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (265237 => 265238)
--- trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2020-08-04 01:51:14 UTC (rev 265237)
+++ trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm 2020-08-04 02:33:28 UTC (rev 265238)
@@ -1388,7 +1388,26 @@
if (!self.webView._retainingActiveFocusedState) {
// We need to complete the editing operation before we blur the element.
[self _endEditing];
- if ((reason == EndEditingReasonAccessoryDone && !WebKit::currentUserInterfaceIdiomIsPad()) || _keyboardDidRequestDismissal || self._shouldUseLegacySelectPopoverDismissalBehavior) {
+
+ auto shouldBlurFocusedElement = [&] {
+ if (_keyboardDidRequestDismissal)
+ return true;
+
+ if (self._shouldUseLegacySelectPopoverDismissalBehavior)
+ return true;
+
+ if (reason == EndEditingReasonAccessoryDone) {
+ if (_focusRequiresStrongPasswordAssistance)
+ return true;
+
+ if (!WebKit::currentUserInterfaceIdiomIsPad())
+ return true;
+ }
+
+ return false;
+ };
+
+ if (shouldBlurFocusedElement()) {
_page->blurFocusedElement();
// Don't wait for WebPageProxy::blurFocusedElement() to round-trip back to us to hide the keyboard
// because we know that the user explicitly requested us to do so.
Modified: trunk/Tools/ChangeLog (265237 => 265238)
--- trunk/Tools/ChangeLog 2020-08-04 01:51:14 UTC (rev 265237)
+++ trunk/Tools/ChangeLog 2020-08-04 02:33:28 UTC (rev 265238)
@@ -1,3 +1,16 @@
+2020-08-03 Wenson Hsieh <wenson_hs...@apple.com>
+
+ Allow -accessoryDone to blur the focused element on iPad when AutoFilling strong passwords
+ https://bugs.webkit.org/show_bug.cgi?id=215105
+ <rdar://problem/65143984>
+
+ Reviewed by Tim Horton.
+
+ Add an API test that exercises the behavior change when run on iPad simulator.
+
+ * TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
+ * TestWebKitAPI/ios/UIKitSPI.h:
+
2020-08-03 Tim Horton <timothy_hor...@apple.com>
Occasional crashes when running nested runloops while using UIWebView
Modified: trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm (265237 => 265238)
--- trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm 2020-08-04 01:51:14 UTC (rev 265237)
+++ trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm 2020-08-04 02:33:28 UTC (rev 265238)
@@ -691,6 +691,29 @@
EXPECT_TRUE([[actual allValues] containsObject:expected]);
}
+TEST(KeyboardInputTests, TestWebViewAccessoryDoneDuringStrongPasswordAssistance)
+{
+ auto webView = adoptNS([[TestWKWebView alloc] initWithFrame:CGRectMake(0, 0, 320, 500)]);
+ auto inputDelegate = adoptNS([[TestInputDelegate alloc] init]);
+
+ [inputDelegate setFocusStartsInputSessionPolicyHandler:[&] (WKWebView *, id <_WKFocusedElementInfo>) -> _WKFocusStartsInputSessionPolicy {
+ return _WKFocusStartsInputSessionPolicyAllow;
+ }];
+
+ [inputDelegate setFocusRequiresStrongPasswordAssistanceHandler:[&] (WKWebView *, id <_WKFocusedElementInfo>) {
+ return YES;
+ }];
+
+ [webView _setInputDelegate:inputDelegate.get()];
+
+ [webView synchronouslyLoadHTMLString:@"<input type='password' id='input'>"];
+ [webView evaluateJavaScriptAndWaitForInputSessionToChange:@"document.getElementById('input').focus()"];
+ EXPECT_WK_STREQ("INPUT", [webView stringByEvaluatingJavaScript:@"document.activeElement.tagName"]);
+ [(id <UIWebFormAccessoryDelegate>)[webView textInputContentView] accessoryDone];
+ EXPECT_WK_STREQ("BODY", [webView stringByEvaluatingJavaScript:@"document.activeElement.tagName"]);
+ EXPECT_TRUE([webView _contentViewIsFirstResponder]);
+}
+
TEST(KeyboardInputTests, SupportsImagePaste)
{
auto inputDelegate = adoptNS([[TestInputDelegate alloc] init]);
Modified: trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h (265237 => 265238)
--- trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h 2020-08-04 01:51:14 UTC (rev 265237)
+++ trunk/Tools/TestWebKitAPI/ios/UIKitSPI.h 2020-08-04 02:33:28 UTC (rev 265238)
@@ -171,6 +171,10 @@
@interface UIWKAutocorrectionContext : NSObject
@end
+@protocol UIWebFormAccessoryDelegate
+- (void)accessoryDone;
+@end
+
@protocol UIWKInteractionViewProtocol
- (void)pasteWithCompletionHandler:(void (^)(void))completionHandler;
- (void)requestAutocorrectionRectsForString:(NSString *)input withCompletionHandler:(void (^)(UIWKAutocorrectionRects *rectsForInput))completionHandler;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
