[iOS] editing/selection/ios/select-text-after-changing-focus.html sometimes fails
authorwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 29 Jun 2020 21:26:11 +0000 (21:26 +0000)
committerwenson_hsieh@apple.com <wenson_hsieh@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Mon, 29 Jun 2020 21:26:11 +0000 (21:26 +0000)
https://bugs.webkit.org/show_bug.cgi?id=213745
Work towards <rdar://problem/64808138>

Reviewed by Tim Horton.

Source/WebKit:

This test first taps an input field to focus it, taps a button below the input field to focus the button and
dismiss the keyboard, and finally long presses to select a word below the button. On recent iOS 14 builds, this
test occasionally fails due to recent changes in UIKit that may cause the callout bar appearance callback to
fire after focusing the input field. If this happens, we end up showing the callout bar with a single option to
"Select All" (despite the field being empty), and the subsequent tap that's intended to hit the button instead
hit-tests to this callout bar item. The tests subsequently times out waiting for the keyboard to dismiss, which
never happens because the input field remains focused.

Showing the "Select All" callout bar option in empty text fields is inconsistent with the rest of the platform
(iOS), and appears to have been unintentionally introduced in iOS 12 by <https://trac.webkit.org/r231726>. While
it's still unknown which exact system changes caused this test to begin timing out, we can at least fix it by
addressing this existing regression in behavior.

* UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView canPerformActionForWebView:withSender:]):

Check `-hasContent` here, instead of just checking if the selection is a caret. Note that we don't need to check
whether the selection is none separately, since `-hasContent` will always return `NO` if there is no selection.

Tools:

See WebKit/ChangeLog for more details. If this test happens to be run after another test that has written
something to the pasteboard, it will still fail due to the callout menu showing up with the option to paste.
Mitigate this by clearing the contents of the system pasteboard between tests, such that content copied from
previous tests doesn't change the behavior of subsequent tests.

* WebKitTestRunner/ios/TestControllerIOS.mm:
(WTR::TestController::platformResetStateToConsistentValues):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@263693 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WebKit/ChangeLog
Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
Tools/ChangeLog
Tools/WebKitTestRunner/ios/TestControllerIOS.mm

index db8c3d5..7adbb7f 100644 (file)
@@ -1,3 +1,30 @@
+2020-06-29  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        [iOS] editing/selection/ios/select-text-after-changing-focus.html sometimes fails
+        https://bugs.webkit.org/show_bug.cgi?id=213745
+        Work towards <rdar://problem/64808138>
+
+        Reviewed by Tim Horton.
+
+        This test first taps an input field to focus it, taps a button below the input field to focus the button and
+        dismiss the keyboard, and finally long presses to select a word below the button. On recent iOS 14 builds, this
+        test occasionally fails due to recent changes in UIKit that may cause the callout bar appearance callback to
+        fire after focusing the input field. If this happens, we end up showing the callout bar with a single option to
+        "Select All" (despite the field being empty), and the subsequent tap that's intended to hit the button instead
+        hit-tests to this callout bar item. The tests subsequently times out waiting for the keyboard to dismiss, which
+        never happens because the input field remains focused.
+
+        Showing the "Select All" callout bar option in empty text fields is inconsistent with the rest of the platform
+        (iOS), and appears to have been unintentionally introduced in iOS 12 by <https://trac.webkit.org/r231726>. While
+        it's still unknown which exact system changes caused this test to begin timing out, we can at least fix it by
+        addressing this existing regression in behavior.
+
+        * UIProcess/ios/WKContentViewInteraction.mm:
+        (-[WKContentView canPerformActionForWebView:withSender:]):
+
+        Check `-hasContent` here, instead of just checking if the selection is a caret. Note that we don't need to check
+        whether the selection is none separately, since `-hasContent` will always return `NO` if there is no selection.
+
 2020-06-29  Sam Weinig  <weinig@apple.com>
 
         Remove remaining makeSimpleColorFrom* variants
index 4a33cc8..45a0758 100644 (file)
@@ -3447,18 +3447,15 @@ WEBCORE_COMMAND_FOR_WEBVIEW(pasteAndMatchStyle);
 
     if (action == @selector(select:)) {
         // Disable select in password fields so that you can't see word boundaries.
-        return !editorState.isInPasswordField && [self hasContent] && !editorState.selectionIsNone && !editorState.selectionIsRange;
+        return !editorState.isInPasswordField && !editorState.selectionIsRange && self.hasContent;
     }
 
     if (action == @selector(selectAll:)) {
-        // By platform convention we don't show Select All in the callout menu for a range selection.
-        if ([sender isKindOfClass:UIMenuController.class])
-            return !editorState.selectionIsNone && !editorState.selectionIsRange;
-#if USE(UIKIT_KEYBOARD_ADDITIONS)
+        if ([sender isKindOfClass:UIMenuController.class]) {
+            // By platform convention we don't show Select All in the callout menu for a range selection.
+            return !editorState.selectionIsRange && self.hasContent;
+        }
         return YES;
-#else
-        return !editorState.selectionIsNone && self.hasContent;
-#endif
     }
 
     if (action == @selector(replace:))
index 13a77b6..fff44c3 100644 (file)
@@ -1,3 +1,19 @@
+2020-06-29  Wenson Hsieh  <wenson_hsieh@apple.com>
+
+        [iOS] editing/selection/ios/select-text-after-changing-focus.html sometimes fails
+        https://bugs.webkit.org/show_bug.cgi?id=213745
+        Work towards <rdar://problem/64808138>
+
+        Reviewed by Tim Horton.
+
+        See WebKit/ChangeLog for more details. If this test happens to be run after another test that has written
+        something to the pasteboard, it will still fail due to the callout menu showing up with the option to paste.
+        Mitigate this by clearing the contents of the system pasteboard between tests, such that content copied from
+        previous tests doesn't change the behavior of subsequent tests.
+
+        * WebKitTestRunner/ios/TestControllerIOS.mm:
+        (WTR::TestController::platformResetStateToConsistentValues):
+
 2020-06-29  Fujii Hironori  <Hironori.Fujii@sony.com>
 
         [Win] run-webkit-tests is failing to run DRT and WTR without --architecture x86_64
index 0d10295..aac7a35 100644 (file)
@@ -155,6 +155,7 @@ bool TestController::platformResetStateToConsistentValues(const TestOptions& opt
 {
     cocoaResetStateToConsistentValues(options);
 
+    [UIPasteboard generalPasteboard].items = @[ ];
     [[UIApplication sharedApplication] _cancelAllTouches];
     [[UIDevice currentDevice] setOrientation:UIDeviceOrientationPortrait animated:NO];
     UIKeyboardPreferencesController *keyboardPreferences = UIKeyboardPreferencesController.sharedPreferencesController;