Changeset 243153 in webkit

Timestamp:

Mar 19, 2019 11:25:21 AM (5 years ago)

Author:

dbates@webkit.org

Message:

[iOS] Focus not preserved when switching between tabs
​https://bugs.webkit.org/show_bug.cgi?id=195820
<rdar://problem/43614450>

Reviewed by Brent Fulgham.

Source/WebKit:

Fixes a usability annoyance when using a hardware keyboard; focus is not preserved when switching between tabs.
Do not unconditionally tell the WebProcess to blur the currently focused element when the content view (WKContentView)
resigns first responder. Instead only tell it to blur when the content view is resigning because either the
accessory view was dismissed (Done button was pressed) or the keyboard was dismissed (the hide keyboard button
was pressed).

• UIProcess/ios/WKContentViewInteraction.h:
• UIProcess/ios/WKContentViewInteraction.mm: Add new ivar to track whether the content view is resigning

first responder status because the accessory view is being dismissed.
(-[WKContentView resignFirstResponderForWebView]): Only tell WebKit to blur the focused element if we are
resigning because the accessory view is being dismissed or the keyboard was hidden. We continue to do all
other steps when resigning, including hiding the keyboard. Note that by not telling WebKit to blur the
focused element we let it's focus controller manage the focused element with respect to the current
page activation state (i.e. whether the content view is first responder or not). When the content view
becomes the first responder then WebKit's focus controller will be told that the page has become activated
and will tell the UIProcess to focus the currently focused element, which will bring up the keyboard.
(-[WKContentView accessoryDone]): Update state so we know that a subsequent call to resign first responder
was due to the accessory view being dismissed.

Tools:

Add tests to ensure that we restore focus when resigning and becoming first responder.

• TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:

(TestWebKitAPI::TEST):

Location:

trunk

Files:

• Source/WebKit/ChangeLog (modified) (1 diff)
• Source/WebKit/UIProcess/ios/WKContentViewInteraction.h (modified) (1 diff)
• Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm (modified) (2 diffs)
• Tools/ChangeLog (modified) (1 diff)
• Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm (modified) (3 diffs)

trunk/Source/WebKit/ChangeLog

@@ +1 @@
+2019-03-19  Daniel Bates  <dabates@apple.com>
+
+        [iOS] Focus not preserved when switching between tabs
+        https://bugs.webkit.org/show_bug.cgi?id=195820
+        <rdar://problem/43614450>
+
+        Reviewed by Brent Fulgham.
+
+        Fixes a usability annoyance when using a hardware keyboard; focus is not preserved when switching between tabs.
+        Do not unconditionally tell the WebProcess to blur the currently focused element when the content view (WKContentView)
+        resigns first responder. Instead only tell it to blur when the content view is resigning because either the
+        accessory view was dismissed (Done button was pressed) or the keyboard was dismissed (the hide keyboard button
+        was pressed).
+
+        * UIProcess/ios/WKContentViewInteraction.h:
+        * UIProcess/ios/WKContentViewInteraction.mm: Add new ivar to track whether the content view is resigning
+        first responder status because the accessory view is being dismissed.
+        (-[WKContentView resignFirstResponderForWebView]): Only tell WebKit to blur the focused element if we are
+        resigning because the accessory view is being dismissed or the keyboard was hidden. We continue to do all
+        other steps when resigning, including hiding the keyboard. Note that by not telling WebKit to blur the
+        focused element we let it's focus controller manage the focused element with respect to the current
+        page activation state (i.e. whether the content view is first responder or not). When the content view
+        becomes the first responder then WebKit's focus controller will be told that the page has become activated
+        and will tell the UIProcess to focus the currently focused element, which will bring up the keyboard.
+        (-[WKContentView accessoryDone]): Update state so we know that a subsequent call to resign first responder
+        was due to the accessory view being dismissed.
+
 2019-03-19  Per Arne Vollan  <pvollan@apple.com>
 

trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.h

@@ -312 +312 @@
     BOOL _becomingFirstResponder;
     BOOL _resigningFirstResponder;
+    BOOL _dismissingAccessory;
     BOOL _needsDeferredEndScrollingSelectionUpdate;
     BOOL _isChangingFocus;

trunk/Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm

@@ -1175 +1175 @@
         // We need to complete the editing operation before we blur the element.
         [self _endEditing];
-        _page->blurFocusedElement();
+        if (_dismissingAccessory || _keyboardDidRequestDismissal)
+            _page->blurFocusedElement();
     }
 
@@ -3692 +3693 @@
 - (void)accessoryDone
 {
+    SetForScope<BOOL> dismissingAccessoryScope { _dismissingAccessory, YES };
     [self resignFirstResponder];
 }

trunk/Tools/ChangeLog

@@ +1 @@
+2019-03-19  Daniel Bates  <dabates@apple.com>
+
+        [iOS] Focus not preserved when switching between tabs
+        https://bugs.webkit.org/show_bug.cgi?id=195820
+        <rdar://problem/43614450>
+
+        Reviewed by Brent Fulgham.
+
+        Add tests to ensure that we restore focus when resigning and becoming first responder.
+
+        * TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
+        (TestWebKitAPI::TEST):
+
 2019-03-19  Alex Christensen  <achristensen@webkit.org>
 

trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm

@@ -275 +275 @@
 }
 
-TEST(KeyboardInputTests, CaretSelectionRectAfterRestoringFirstResponder)
+TEST(KeyboardInputTests, CaretSelectionRectAfterRestoringFirstResponderWithRetainActiveFocusedState)
 {
     auto expectedCaretRect = CGRectMake(16, 13, 2, 15);
@@ -291 +291 @@
 }
 
-TEST(KeyboardInputTests, RangedSelectionRectAfterRestoringFirstResponder)
+TEST(KeyboardInputTests, RangedSelectionRectAfterRestoringFirstResponderWithRetainActiveFocusedState)
 {
     NSArray *expectedSelectionRects = @[ [NSValue valueWithCGRect:CGRectMake(16, 13, 24, 15)] ];
@@ -304 +304 @@
     [webView resignFirstResponder];
     restoreActiveFocusState();
+    [webView waitForSelectionViewRectsToBecome:@[ ]];
+
+    [webView becomeFirstResponder];
+    [webView waitForSelectionViewRectsToBecome:expectedSelectionRects];
+}
+
+TEST(KeyboardInputTests, CaretSelectionRectAfterRestoringFirstResponder)
+{
+    auto expectedCaretRect = CGRectMake(16, 13, 2, 15);
+    auto webView = webViewWithAutofocusedInput();
+    EXPECT_WK_STREQ("INPUT", [webView stringByEvaluatingJavaScript:@"document.activeElement.tagName"]);
+    [webView waitForCaretViewFrameToBecome:expectedCaretRect];
+
+    [webView resignFirstResponder];
+    [webView waitForCaretViewFrameToBecome:CGRectZero];
+
+    [webView becomeFirstResponder];
+    [webView waitForCaretViewFrameToBecome:expectedCaretRect];
+}
+
+TEST(KeyboardInputTests, RangedSelectionRectAfterRestoringFirstResponder)
+{
+    NSArray *expectedSelectionRects = @[ [NSValue valueWithCGRect:CGRectMake(16, 13, 24, 15)] ];
+
+    auto webView = webViewWithAutofocusedInput();
+    [[webView textInputContentView] insertText:@"hello"];
+    [webView selectAll:nil];
+    EXPECT_WK_STREQ("INPUT", [webView stringByEvaluatingJavaScript:@"document.activeElement.tagName"]);
+    [webView waitForSelectionViewRectsToBecome:expectedSelectionRects];
+
+    [webView resignFirstResponder];
     [webView waitForSelectionViewRectsToBecome:@[ ]];