Changeset 248496 in webkit


Ignore:
Timestamp:
Aug 9, 2019 9:00:23 PM (5 years ago)
Author:
Wenson Hsieh
Message:

KeyboardInputTests.CaretSelectionRectAfterRestoringFirstResponder API tests time out on iPad
https://bugs.webkit.org/show_bug.cgi?id=200604
<rdar://problem/51273130>

Reviewed by Megan Gardner.

Tweak some API tests so that they work on iPad simulator. These tests checked that the final caret rect was
{{16, 13}, {2, 15}}; however, this is only correct behavior on iPhone, where we will scale the page so that the
focused element's font size is legible. Note that when the page is scaled, we scale the height but not the
width of the caret, which is why the width of the caret (in content coordinates) decreases while the height
remains the same.

We don't have the same behavior on iPad, so the expected caret rect is {{16, 13}, {3, 15}}, which is equal to
the caret rect at initial scale 1.

  • TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
Location:
trunk/Tools
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • trunk/Tools/ChangeLog

    r248491 r248496  
     12019-08-09  Wenson Hsieh  <wenson_hsieh@apple.com>
     2
     3        KeyboardInputTests.CaretSelectionRectAfterRestoringFirstResponder API tests time out on iPad
     4        https://bugs.webkit.org/show_bug.cgi?id=200604
     5        <rdar://problem/51273130>
     6
     7        Reviewed by Megan Gardner.
     8
     9        Tweak some API tests so that they work on iPad simulator. These tests checked that the final caret rect was
     10        {{16, 13}, {2, 15}}; however, this is only correct behavior on iPhone, where we will scale the page so that the
     11        focused element's font size is legible. Note that when the page is scaled, we scale the height but not the
     12        width of the caret, which is why the width of the caret (in content coordinates) decreases while the height
     13        remains the same.
     14
     15        We don't have the same behavior on iPad, so the expected caret rect is {{16, 13}, {3, 15}}, which is equal to
     16        the caret rect at initial scale 1.
     17
     18        * TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm:
     19
    1202019-08-09  Ali Juma  <ajuma@chromium.org>
    221
  • trunk/Tools/TestWebKitAPI/Tests/ios/KeyboardInputTestsIOS.mm

    r248487 r248496  
    326326TEST(KeyboardInputTests, CaretSelectionRectAfterRestoringFirstResponderWithRetainActiveFocusedState)
    327327{
    328     auto expectedCaretRect = CGRectMake(16, 13, 2, 15);
     328    // This difference in caret width is due to the fact that we don't zoom in to the input field on iPad, but do on iPhone.
     329    auto expectedCaretRect = CGRectMake(16, 13, UIDevice.currentDevice.userInterfaceIdiom == UIUserInterfaceIdiomPad ? 3 : 2, 15);
    329330    auto webView = webViewWithAutofocusedInput();
    330331    EXPECT_WK_STREQ("INPUT", [webView stringByEvaluatingJavaScript:@"document.activeElement.tagName"]);
     
    361362TEST(KeyboardInputTests, CaretSelectionRectAfterRestoringFirstResponder)
    362363{
    363     auto expectedCaretRect = CGRectMake(16, 13, 2, 15);
     364    // This difference in caret width is due to the fact that we don't zoom in to the input field on iPad, but do on iPhone.
     365    auto expectedCaretRect = CGRectMake(16, 13, UIDevice.currentDevice.userInterfaceIdiom == UIUserInterfaceIdiomPad ? 3 : 2, 15);
    364366    auto webView = webViewWithAutofocusedInput();
    365367    EXPECT_WK_STREQ("INPUT", [webView stringByEvaluatingJavaScript:@"document.activeElement.tagName"]);
Note: See TracChangeset for help on using the changeset viewer.